3. New Features and Enhancements in Spring 3.1
Prev | Part II. What's New in Spring 3 | Next

## 3. New Features and Enhancements in Spring 3.1

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.

## 3.1 Overview of new features

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.

### 3.1.1 Cache Abstraction

- Chapter 28, Cache Abstraction

- Cache Abstraction (SpringSource team blog)

### 3.1.2 Bean Definition Profiles

- XML profiles (SpringSource Team Blog)

- Introducing @Profile (SpringSource Team Blog)

- See org.springframework.context.annotation.Configuration Javadoc

- See org.springframework.context.annotation.Profile Javadoc

### 3.1.3 Environment Abstraction

- Environment Abstraction (SpringSource Team Blog)

- See org.springframework.core.env.Environment Javadoc

### 3.1.4 PropertySource Abstraction

- 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

### 3.1.5 Code equivalents for Spring's XML namespaces

Code-based equivalents to popular Spring XML namespace elements <context:component-scan/>, <tx:annotation-driven/> and <mvc:annotation-driven> have been developed, most in the form of `@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

### 3.1.6 Support for Hibernate 4.x

- See Javadoc for classes within the new org.springframework.orm.hibernate4 package

### 3.1.7 TestContext framework support for @Configuration classes and bean definition profiles

The `@ContextConfiguration` annotation now supports supplying `@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.

- Spring 3.1 M2: Testing with @Configuration Classes and Profiles (SpringSource Team Blog)

- See Section 10.3.5, “Spring TestContext Framework”

- See the section called “Context configuration with @Configuration classes” and `org.springframework.test.context.ContextConfiguration` Javadoc

- See `org.springframework.test.context.ActiveProfiles` Javadoc

- See `org.springframework.test.context.SmartContextLoader` Javadoc

- See `org.springframework.test.context.support.DelegatingSmartContextLoader` Javadoc

- See `org.springframework.test.context.support.AnnotationConfigContextLoader` Javadoc

### 3.1.8 c: namespace for more concise constructor injection

- Section 4.4.2.7, “XML shortcut with the c-namespace”

### 3.1.9 Support for injection against non-standard JavaBeans setters

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'.

### 3.1.10 Support for Servlet 3 code-based configuration of Servlet Container

The new `WebApplicationInitializer` 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 `WebApplicationInitializer`

### 3.1.11 Support for Servlet 3 MultipartResolver

- See org.springframework.web.multipart.support.StandardServletMultipartResolver Javadoc

### 3.1.12 JPA EntityManagerFactory bootstrapping without persistence.xml

In standard JPA, persistence units get defined through `META-INF/persistence.xml` files in specific jar files which will in turn get searched for `@Entity` classes. 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 initializer.

### 3.1.13 New HandlerMethod-based Support Classes For Annotated Controller Processing

Spring 3.1 introduces a new set of support classes for processing requests with annotated controllers:

- `RequestMappingHandlerMapping`

- `RequestMappingHandlerAdapter`

- `ExceptionHandlerExceptionResolver`

These classes are a replacement for the existing:

- `DefaultAnnotationHandlerMapping`

- `AnnotationMethodHandlerAdapter`

- `AnnotationMethodHandlerExceptionResolver`

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 `handler` instance. For example a `HandlerInterceptor` can cast the `handler` from `Object` to `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 16.3.2.1, “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.

### 3.1.14 "consumes" and "produces" conditions in @RequestMapping

Improved support for specifying media types consumed by a method through the `'Content-Type'` header as well as for producible types specified through the `'Accept'` header. See Section 16.3.2.5, “Consumable Media Types” and Section 16.3.2.6, “Producible Media Types”

### 3.1.15 Flash Attributes and `RedirectAttributes`

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 16.3.3.10, “Specifying redirect and flash attributes” for more details.

### 3.1.16 URI Template Variable Enhancements

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 `@ModelAttribute` method arguments.

- @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 (e.g. `"redirect:/blog/{year}/{month}"`). When expanding the placeholders, URI template variables from the current request are automatically considered.

- An `@ModelAttribute` method 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.

### 3.1.17 `@Valid` On @RequestBody Controller Method Arguments

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.

### 3.1.18 `@RequestPart` Annotation On Controller Method Arguments

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”.

### 3.1.19 `UriComponentsBuilder` and `UriComponents`

A new `UriComponents` class has been added, which is an immutable container of URI components providing access to all contained URI components. A nenw `UriComponentsBuilder` class is also provided to help create `UriComponents` instances. 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` especially since `UriTemplate` relies on those same classes internally.

A `ServletUriComponentsBuilder` sub-class provides static factory methods to copy information from a Servlet request. See Section 16.7, “Building URIs”.

Prev | Up | Next
2. New Features and Enhancements in Spring 3.0 | Home | Part III. Core Technologies