diff --git a/spring-framework-reference/src/new-in-3.1.xml b/spring-framework-reference/src/new-in-3.1.xml index 0b655279789..4d3795fd41f 100644 --- a/spring-framework-reference/src/new-in-3.1.xml +++ b/spring-framework-reference/src/new-in-3.1.xml @@ -5,22 +5,24 @@ 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 M2 - has just been released. + currently under development, and at the time of this writing Spring 3.1 RC1 + is being prepared for release.
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 these cases, fully-qualified classnames are given. + 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.
Cache Abstraction + - + + @@ -28,102 +30,135 @@
+
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.Configuration + Javadoc + - See org.springframework.context.annotation.Profile Javadoc + See org.springframework.context.annotation.Profile + Javadoc
+
Environment Abstraction + Environment Abstraction (SpringSource Team Blog) + See org.springframework.core.env.Environment Javadoc
+
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 + See org.springframework.context.annotation.PropertySource + Javadoc
+
Code equivalents for Spring's XML namespaces - 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 @Enable annotations, - for use in conjunction with Spring's @Configuration + + 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 + @Enable annotations, for use in + conjunction with Spring's @Configuration classes. + - See org.springframework.scheduling.annotation.Configuration Javadoc + See org.springframework.scheduling.annotation.Configuration + Javadoc + - See org.springframework.scheduling.annotation.EnableAsync 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.EnableLoadTimeWeaving Javadoc + - See org.springframework.scheduling.annotation.EnableWebMvc Javadoc + See org.springframework.scheduling.annotation.EnableWebMvc + Javadoc
+
Builder-style APIs for code-based Hibernate configuration + SessionFactoryBuilder and - AnnotationSessionFactoryBuilder classes have been designed - for use within @Bean methods in + AnnotationSessionFactoryBuilder classes have been + designed for use within @Bean methods in @Configuration classes. + - See org.springframework.orm.hibernate3.SessionFactoryBuilder Javadoc + See org.springframework.orm.hibernate3.SessionFactoryBuilder + Javadoc + See org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBuilder @@ -131,55 +166,114 @@
+
- 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. + 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. + - See org.springframework.test.context.ContextConfiguration Javadoc + Spring + 3.1 M2: Testing with @Configuration Classes and Profiles + (SpringSource Team Blog) + + + + See + + + + See + 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
+
c: namespace for more concise constructor injection + - +
+
- 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'. + 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'.
+
- 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. + 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 + See org.springframework.web.WebApplicationInitializer + Javadoc + - Diff from Spring's Greenhouse - reference application demonstrating migration from web.xml to + Diff from Spring's + Greenhouse reference application demonstrating migration + from web.xml to WebApplicationInitializer
+
Support for Servlet 3 MultipartResolver + See @@ -188,120 +282,189 @@
+
- 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. + 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.
+
- 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: + 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 + + RequestMappingHandlerMapping + + + + RequestMappingHandlerAdapter + + + + ExceptionHandlerExceptionResolver + + These classes are a replacement for the existing: + - DefaultAnnotationHandlerMapping - AnnotationMethodHandlerAdapter - AnnotationMethodHandlerExceptionResolver + + 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. + + 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 - + + 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 + 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. + + 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.
+
- "consumes" and "produces" conditions in <interface>@RequestMapping</interface> - 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 and - - + "consumes" and "produces" conditions in + <interface>@RequestMapping</interface> + + 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 and
+
- Flash Attributes and <interfacename>RedirectAttributes</interfacename> - 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 . - - - In annotated controllers, an @RequestMapping - method can add flash attributes by declaring a method argument of type + Flash Attributes and + <interfacename>RedirectAttributes</interfacename> + + 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 . + + 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 - for more details. - + a redirect scenario. See + for more details.
-
- 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. - - -
-
- <interfacename>@Valid</interfacename> On - <interface>@RequestBody</interface> 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. -
+
- <interfacename>@RequestPart</interfacename> Annotation On Controller Method Arguments - This new annotation provides access to the content of a - "multipart/form-data" request part. - See and - . + 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. + + +
+ +
+ <interfacename>@Valid</interfacename> On + <interface>@RequestBody</interface> 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. +
+ +
+ <interfacename>@RequestPart</interfacename> Annotation On + Controller Method Arguments + + This new annotation provides access to the content of a + "multipart/form-data" request part. See and .
diff --git a/spring-framework-reference/src/testing.xml b/spring-framework-reference/src/testing.xml index acf7d8aa0ba..cc8aa8ef9e7 100644 --- a/spring-framework-reference/src/testing.xml +++ b/spring-framework-reference/src/testing.xml @@ -993,7 +993,7 @@ public void testProcessRepeatedly() { ContextLoader: Strategy - interface for loading an + interface introduced in Spring 2.5 for loading an ApplicationContext for an integration test managed by the Spring TestContext Framework. @@ -1028,7 +1028,7 @@ public void testProcessRepeatedly() { AnnotationConfigContextLoader or a GenericXmlContextLoader depending either on the configuration declared for the test class or on - the presence of default locations or configuration + the presence of default locations or default configuration classes. @@ -1039,8 +1039,8 @@ public void testProcessRepeatedly() { - GenericXmlContextLoader: loads - and application context from XML resource locations. + GenericXmlContextLoader: loads an + application context from XML resource locations. @@ -1151,8 +1151,8 @@ public class MyTest { @ContextConfiguration supports an alias for the locations attribute through the - standard value attribute. Thus, if you do not - need to configure a custom + standard Java value attribute. Thus, if you do + not need to configure a custom ContextLoader, you can omit the declaration of the locations attribute name and declare the resource locations by using the shorthand format @@ -1345,9 +1345,10 @@ public class ExtendedTest extends BaseTest { linkend="integration-testing-annotations-spring" />). This instructs Spring to reload the configuration and rebuild the application context before executing the next test. Note that support for the - @DirtiesContext annotation is enabled - via the DirtiesContextTestExecutionListener - which is enabled by default. + @DirtiesContext annotation is + provided by the + DirtiesContextTestExecutionListener which is + enabled by default.