diff --git a/build-spring-framework/resources/changelog.txt b/build-spring-framework/resources/changelog.txt index b63f6d93f2..386e98a62f 100644 --- a/build-spring-framework/resources/changelog.txt +++ b/build-spring-framework/resources/changelog.txt @@ -52,7 +52,10 @@ Changes in version 3.1 RC1 (2011-09-xx) * extended Servlet API mocks for Servlet 3.0 forward compatibility as far as possible * made MockHttpServletResponse compatible with Servlet 3.0 getHeader(s) method returning Strings * added getHeaderValue(s) method to MockHttpServletResponse for raw value access - +* add flash attribute support through FlashMap and FlashMapManager abstractions +* add RedirectAttributes abstraction as supported method argument type of @RequestMapping methods +* add "ignoreDefaultModelOnRedirect" flag to RequestMappingHandlerAdapter +* add support for @RequestPart annotated controller method arguments Changes in version 3.1 M2 (2011-06-08) -------------------------------------- @@ -64,17 +67,16 @@ Changes in version 3.1 M2 (2011-06-08) * AnnotatedBeanDefinitionReader now inherits Environment of supplied BeanDefinitionRegistry * eliminated @Feature support in favor of @Enable* and framework-provided @Configuration classes * introduced @EnableTransactionManagement, @EnableScheduling, etc -* introduced @EnableWebMvc to provide default configuration for Spring MVC applications -* introduced HandlerMethod abstraction representing a Spring MVC controller method -* added HandlerMapping/HandlerAdapter/HandlerExceptionResolver HandlerMethod-based implementations -* enabled HandlerMethod-based infrastructure through the mvc namespace and Java-based configuration -* support for automatically adding @PathVariables to the model -* support for including @PathVariables in data binding -* support for URI template variables in view names with the "redirect:" prefix -* added a flag for extracting the value from single-key models in MappingJacksonJsonView -* added support for @Valid with @RequestBody arguments +* add Java config alternative to MVC namespace via @EnableWebMvc annotation +* introduce HandlerMethod abstraction selecting and invoking @RequestMapping methods +* add HandlerMethod-based implementations of HandlerMapping, HandlerAdapter, HandlerExceptionResolver +* merge @PathVariables in the model before rendering except for JSON/XML serialization/marshalling. +* use @PathVariables in addition to request parameters in data binding +* support URI variable placeholders in "redirect:" prefixed view names +* add flag to extract value from single-key model in MappingJacksonJsonView +* support @Valid on @RequestBody method arguments * allow bean references in mvc:interceptor namespace elements -* consolidated the initialization and use of MappedInterceptors in AbstractHandlerMapping +* consolidate initialization and use of MappedInterceptors in AbstractHandlerMapping * added Servlet 3.0 based WebApplicationInitializer mechanism for programmatic bootstrapping * added Servlet 3.0 based StandardServletMultipartResolver * added "packagesToScan" feature to LocalContainerEntityManagerFactoryBean (avoiding persistence.xml) diff --git a/org.springframework.web/src/main/java/org/springframework/web/bind/annotation/RequestMapping.java b/org.springframework.web/src/main/java/org/springframework/web/bind/annotation/RequestMapping.java index a7fbf13131..7fe0deaff5 100644 --- a/org.springframework.web/src/main/java/org/springframework/web/bind/annotation/RequestMapping.java +++ b/org.springframework.web/src/main/java/org/springframework/web/bind/annotation/RequestMapping.java @@ -108,6 +108,12 @@ import java.lang.annotation.Target; *
  • {@link java.util.Map} / {@link org.springframework.ui.Model} / * {@link org.springframework.ui.ModelMap} for enriching the implicit model * that will be exposed to the web view. + *
  • {@link org.springframework.web.servlet.mvc.support.RedirectAttributes} + * to specify the exact set of attributes to use in case of a redirect + * and also to add flash attributes (attributes stored temporarily on the + * server-side to make them available to the request after the redirect). + * {@code RedirectAttributes} is used instead of the implicit model if the + * method returns a "redirect:" prefixed view name or {@code RedirectView}. *
  • Command/form objects to bind parameters to: as bean properties or fields, * with customizable type conversion, depending on {@link InitBinder} methods * and/or the HandlerAdapter configuration - see the "webBindingInitializer" diff --git a/spring-framework-reference/src/mvc.xml b/spring-framework-reference/src/mvc.xml index 25c243e894..4bb84eaea2 100644 --- a/spring-framework-reference/src/mvc.xml +++ b/spring-framework-reference/src/mvc.xml @@ -1132,6 +1132,18 @@ public class RelativePathUriTemplateController { view. + + + org.springframework.web.servlet.mvc.support.RedirectAttributes + to specify the exact set of attributes to use in case of a redirect + and also to add flash attributes (attributes stored temporarily on + the server-side to make them available to the request after the redirect). + RedirectAttributes is used instead of the implicit + model if the method returns a "redirect:" prefixed view name or + RedirectView. + + + Command or form objects to bind request parameters to bean properties (via setters) or directly to fields, with @@ -1697,9 +1709,56 @@ public class EditPetForm { + +
    + Specifying redirect and flash attributes + + By default all model attributes are considered to be exposed as + URI template variables in the redirect URL. Of the remaining attributes + those that are primitive types or collections/arrays of primitive types + are automatically appended as query parameters. + + + In annotated controllers however the model may contain + additional attributes originally added for rendering + purposes (e.g. drop-down field values). + To gain precise control over the attributes used in a redirect scenario, + an @RequestMapping method can declare an + argument of type RedirectAttributes + and use it to add attributes for use in RedirectView. + If the controller method does redirect, the content of + RedirectAttributes is used. + Otherwise the content of the default Model + is used. + + + + The RequestMappingHandlerAdapter provides a flag + called "ignoreDefaultModelOnRedirect" that can be + used to indicate the content of the default Model + should never be used if a controller method redirects. + Instead the controller method should declare an attribute of type + RedirectAttributes or if it doesn't do so + no attributes should be passed on to RedirectView. + Both the MVC namespace and the MVC Java config (via + @EnableWebMvc) automatically set + this flag to true. + + + The RedirectAttributes interface can + also be used to add flash attributes. Unlike other redirect attributes, + which end up in the target redirect URL, flash attributes are saved + in the HTTP session (and hence do not appear in the URL). The model of + the controller serving the target redirect URL automatically receives + these flash attributes after which they are removed from the session. + See for an overview of the general + support for flash attributes in Spring MVC. + + +
    - Working with <literal>application/x-www-form-urlencoded</literal> data + Working with <literal>"application/x-www-form-urlencoded"</literal> data The previous sections covered use of @ModelAttribute to support form submission requests from browser clients. The same annotation is @@ -2431,24 +2490,38 @@ public class TimeBasedAccessInterceptor extends HandlerInterceptorAdapter { The RedirectView issues an HttpServletResponse.sendRedirect() call that returns to the client browser as an HTTP redirect. - All model attributes are considered to be exposed as either URI template variables first, - assuming the URL is a URI template such as /account/{number}, - or as HTTP query parameters second. By default String and primitive model attributes - are eligible to be exposed this way. However, this behavior can be extended by - sub-classing RedirectView. Also consider that @PathVariable-annotated - method arguments are automatically added to the model, which is convenient when - redirecting to the same URL using a different HTTP method. For example: + By default all model attributes are considered to be exposed as URI + template variables in the redirect URL. Of the remaining attributes + those that are primitive types or collections/arrays of primitive types + are automatically appended as query parameters. + + + + Appending primitive type attributes as query parameters may be the + desired result if a model instance was prepared specifically for the + redirect. However, in annotated controllers the model may contain + additional attributes added for rendering purposes (e.g. drop-down + field values). To avoid the possibility of having such attributes + appear in the URL an annotated controller can declare an + argument of type RedirectAttributes + and use it to specify the exact attributes to make available to + RedirectView. If the controller method decides + to redirect, the content of RedirectAttributes + is used. Otherwise the content of the model is used. + + + + Note that URI template variables from the present request are automatically + made available when expanding a redirect URL and do not need to be added + explicitly neither through Model nor + RedirectAttributes. For example: @RequestMapping(value = "/files/{path}", method = RequestMethod.POST) -public String upload(@PathVariable String path, ...) { +public String upload(...) { // ... return "redirect:files/{path}"; } - -@RequestMapping(value = "/files/{path}", method = RequestMethod.GET) -public void get(@PathVariable String path, ...) { - // ... -} + If you use RedirectView and the view is created by the controller itself, it is recommended that you configure @@ -2681,6 +2754,73 @@ public class ContentController {
    +
    + Using flash attributes + + Flash attributes provide a way for one request to store attributes + intended for use in another. This is most commonly needed when redirecting + -- e.g. the Post/Redirect/Get pattern. Flash attributes are saved temporarily + before the redirect (typically in the session) to be made available to the + request after the redirect and removed immediately. + + + Spring MVC has two main abstractions in support of flash attributes. + FlashMap is used to hold flash attributes while + FlashMapManager is used to store, retrieve, + and manage FlashMap instances. + + + Flash attribute support is always "on" and does not need to enabled + explicitly although if not used, it never causes HTTP session creation. + On each request there is an "input" FlashMap with + attributes passed from a previous request (if any) and an "output" + FlashMap with attributes to save for a subsequent + request. Both FlashMap instances are accessible + from anywhere in Spring MVC through static methods in + RequestContextUtils. + + + Annotated controllers typically do not need to work with + FlashMap directly. Instead an + @RequestMapping method can accept an argument + of type RedirectAttributes and use it to + add flash attributes for a redirect scenario. Flash attributes added via + RedirectAttributes are automatically + propagated to the "output" FlashMap. Similarly after the + redirect attributes from the "input" FlashMap are + automatically added to the Model + of the controller serving the target URL. + + + + Matching requests to flash attributes + The concept of flash attributes exists in many other Web frameworks + and has proven to be exposed sometimes to concurrency issues. + This is because by definition flash attributes are + to be stored until the next request. However the very "next" + request may not be the intended recepient but another + asynchronous request (e.g. polling or resource requests) + in which case the flash attributes are removed too early. + + + To reduce the possibility of such issues, + RedirectView automatically "stamps" + FlashMap instances with the path and query + parameters of the target redirect URL. In turn the default + FlashMapManager matches that information to incoming + requests when looking up the "input" FlashMap. + + + This does not eliminate the possibility of a concurrency issue + entirely but nevertheless reducess it greatly with information + that is already available in the redirect URL. + Therefore the use of flash attributes is recommended + mainly for redirect scenarios unless the target URL and/or query + parameters are known. + + +
    +
    Using locales diff --git a/spring-framework-reference/src/new-in-3.1.xml b/spring-framework-reference/src/new-in-3.1.xml index 6992b706e4..8c844fe78a 100644 --- a/spring-framework-reference/src/new-in-3.1.xml +++ b/spring-framework-reference/src/new-in-3.1.xml @@ -240,37 +240,65 @@ recommended going forward.
    - Consumes and Produces <interface>@RequestMapping</interface> Conditions + "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 + 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. +
    - Working With URI Template Variables In Controller Methods - @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 "redirect:/blog/{year}/{month}". - 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. + 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 an 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. + +
    - Validation For <interface>@RequestBody</interface> Method Arguments - An @RequestBody method argument annotated - with @Valid is now automatically validated with the - same Validator instance used to validate - an @ModelAttribute method argument. - Both the MVC namespace and @EnableWebMvc - automatically configure a JSR-303 Validator adapter - provided a JSR-303 implementation is available on the classpath. + <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. + The resulting MethodArgumentNotValidException is handled in the + DefaultHandlerExceptionResolver and results in 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 + +