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 RC1 is being prepared for release.
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 such cases, fully-qualified class names are given. See also Appendix B, Migrating to Spring Framework 3.1
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
and <mvc:annotation-driven> have been developed, most in the
@Enable annotations. These are
designed for use in conjunction with Spring's
@Configuration classes, which were
introduced in Spring 3.0.
See org.springframework.context.annotation.Configuration Javadoc
See org.springframework.context.annotation.ComponentScan Javadoc
See org.springframework.transaction.annotation.EnableTransactionManagement Javadoc
See org.springframework.cache.annotation.EnableCaching Javadoc
See org.springframework.web.servlet.config.annotation.EnableWebMvc Javadoc
See org.springframework.scheduling.annotation.EnableScheduling Javadoc
See org.springframework.scheduling.annotation.EnableAsync Javadoc
See org.springframework.context.annotation.EnableAspectJAutoProxy Javadoc
See org.springframework.context.annotation.EnableLoadTimeWeaving Javadoc
See org.springframework.beans.factory.aspectj.EnableSpringConfigured Javadoc
See Javadoc for classes within the new org.springframework.orm.hibernate4 package
annotation now supports supplying
@Configuration classes for configuring
TestContext. In addition, a new
@ActiveProfiles annotation has been
introduced to support declarative configuration of active bean
definition profiles in
Spring 3.1 M2: Testing with @Configuration Classes and Profiles (SpringSource Team Blog)
See the section called “Context configuration with @Configuration classes”
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'.
builds atop Servlet 3.0's
ServletContainerInitializer support 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
META-INF/persistence.xml 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
@Entity classes. 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
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.
See org.springframework.web.method.support.HandlerMethodArgumentResolver Javadoc
See org.springframework.web.method.support.HandlerMethodReturnValueHandler Javadoc
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
instance. For example a
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.
See Section 188.8.131.52, “New Support Classes for @RequestMapping methods in Spring MVC 3.1” for additional details and a list of features not available with the new support classes.
Improved support for specifying media types consumed by a method
'Content-Type' header as well as for
producible types specified through the
header. See Section 184.108.40.206, “Consumable Media Types” and Section 220.127.116.11, “Producible Media Types”
Flash attributes can now be stored in a
FlashMap and saved in the HTTP session to survive
a redirect. For an overview of the general support for flash attributes
in Spring MVC see Section 16.6, “Using flash attributes”.
In annotated controllers, an
@RequestMapping method can add flash
attributes by declaring a method argument of type
RedirectAttributes. This method argument
can now also be used to get precise control over the attributes used in
a redirect scenario. See Section 18.104.22.168, “Specifying redirect and flash attributes”
for more details.
URI template variables from the current request are used in more places:
URI template variables are used in addition to request
parameters when binding a request to
@PathVariable method argument values are merged into the model before rendering, except in views that generate content in an automated fashion such as JSON serialization or XML marshalling.
A redirect string can contain placeholders for URI variables
expanding the placeholders, URI template variables from the
current request are automatically considered.
argument can be instantiated from a URI template variable provided
there is a registered Converter or PropertyEditor to convert from
a String to the target object type.
An @RequestBody method argument can be
annotated with @Valid to invoke automatic
validation similar to the support for
@ModelAttribute method arguments. A resulting
MethodArgumentNotValidException is handled in the
DefaultHandlerExceptionResolver and results in a
400 response code.
This new annotation provides access to the content of a "multipart/form-data" request part. See Section 16.10.5, “Handling a file upload request from programmatic clients” and Section 16.10, “Spring's multipart (file upload) support”.
UriComponents class has been added,
which is an immutable container of URI components providing
access to all contained URI components.
UriComponentsBuilder class is also
provided to help create
Together the two classes give fine-grained control over all
aspects of preparing a URI including construction, expansion
from URI template variables, and encoding.
In most cases the new classes can be used as a more flexible
alternative to the existing
UriTemplate relies on those
same classes internally.
provides static factory methods to copy information from
a Servlet request. See Section 16.7, “Building URIs”.