Building on the support introduced in Spring 3.0, Spring 3.1 is currently under development, and at the time of this writing Spring 3.1 M2 has just been released.
This is a list of new features for Spring 3.1. Most features do not yet have dedicated reference documentation but do have Javadoc. In these cases, fully-qualified classnames are given.
Environment Abstraction (SpringSource Team Blog)
See org.springframework.core.env.Environment Javadoc
Unified Property Management (SpringSource Team Blog)
See org.springframework.core.env.Environment Javadoc
See org.springframework.core.env.PropertySource Javadoc
See org.springframework.context.annotation.PropertySource Javadoc
Code-based equivalents to popular Spring XML namespace elements such as
<tx:annotation-driven/> and <mvc:annotation-driven> have been
developed, in the form of
for use in conjunction with Spring's
See org.springframework.scheduling.annotation.Configuration Javadoc
See org.springframework.scheduling.annotation.EnableAsync Javadoc
See org.springframework.scheduling.annotation.EnableScheduling Javadoc
See org.springframework.scheduling.annotation.EnableTransactionManagement Javadoc
See org.springframework.scheduling.annotation.EnableWebMvc Javadoc
AnnotationSessionFactoryBuilder classes have been designed
for use within
@Bean methods in
See org.springframework.orm.hibernate3.SessionFactoryBuilder Javadoc
See org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBuilder Javadoc
@ContextConfiguration annotation now
@Configuration classes for
configuring the Spring
TestContext. In addition, a new
@ActiveProfiles annotation has been introduced
to support declarative configuration of active bean definition profiles in
ApplicationContext integration tests.
See org.springframework.test.context.ContextConfiguration Javadoc
Prior to Spring 3.1, in order to inject against a property method it had to conform strictly to JavaBeans property signature rules, namely that any 'setter' method must be void-returning. It is now possible in Spring XML to specify setter methods that return any object type. This is useful when considering designing APIs for method-chaining, where setter methods return a reference to 'this'.
WebApplicationInitializer builds atop
to provide a programmatic alternative to the traditional web.xml.
See org.springframework.web.WebApplicationInitializer Javadoc
Diff from Spring's Greenhouse
reference application demonstrating migration from web.xml to
See org.springframework.web.multipart.support.StandardServletMultipartResolver Javadoc
In standard JPA, persistence units get defined through
files in specific jar files which will in turn get searched for
In many cases, persistence.xml does not contain more than a unit name and relies on defaults and/or
external setup for all other concerns (such as the DataSource to use, etc). For that reason, Spring 3.1
provides an alternative:
LocalContainerEntityManagerFactoryBean accepts a
'packagesToScan' property, specifying base packages to scan for
This is analogous to
AnnotationSessionFactoryBean's property of the same name
for native Hibernate setup, and also to Spring's component-scan feature for regular Spring beans.
Effectively, this allows for XML-free JPA setup at the mere expense of specifying a base package for
entity scanning: a particularly fine match for Spring applications which rely on component scanning
for Spring beans as well, possibly even bootstrapped using a code-based Servlet 3.0 initializer.
Spring 3.1 introduces a new set of support classes for processing requests with annotated controllers:
These classes are a replacement for the existing:
The new classes were developed in response to many requests to make annotation controller support classes more customizable and open for extension. Whereas previously you could configure a custom annotated controller method argument resolver, with the new support classes you can customize the processing for any supported method argument or return value type.
A second notable difference is the introduction of a
HandlerMethod abstraction to represent an
@RequestMapping method. This abstraction is used
throughout by the new support classes as the
For example a
HandlerInterceptor can cast
HandlerMethod and get access to the target
controller method, its annotations, etc.
The new classes are enabled by default by the MVC namespace and by Java-based configuration via @EnableWebMvc. The existing classes will continue to be available but use of the new classes is recommended going forward.
Improved support for specifying media types consumed by a method through the
'Content-Type' header as well as for producible types specified
See Section 184.108.40.206, “Consumable Media Types” and
Section 220.127.116.11, “Producible Media Types”
@PathVariable method arguments are now automatically added to the model. If you declare any @PathVariable arguments on a controller method you no longer need to add them to the model.
Redirect view strings can now be URI templates.
For example a controller can return
The URI template will be expanded with variables from the model, which
of course includes @PathVariable method arguments
that are now automatically added to the model.
URI template variables are now included in data binding in addition to request parameters, which are typically used for populating a model.
An @RequestBody method argument annotated
with @Valid is now automatically validated with the
Validator instance used to validate
an @ModelAttribute method argument.
Both the MVC namespace and @EnableWebMvc
automatically configure a JSR-303
provided a JSR-303 implementation is available on the classpath.