Make it possible to hook in custom ServletRequestDataBinderFactory
by overriding RequestMappingHandlerAdapter.
Create ExtendedServletRequestDataBinder to add URI template vars
to the binding values taking advantage of a new extension hook in
ServletRequestDataBinder to provide additional values to bind.
1. Consider single-purpose return value types like HttpEntity, Model,
View, and ModelAndView ahead of annotations like @ResponseBody and
@ModelAttribute. And reversely consider multi-purpose return value
types like Map, String, and void only after annotations like
@RB and @MA.
2. Order custom argument resolvers and return value handlers after the
built-in ones also clarifying the fact they cannot be used to override
the built-in ones in Javadoc throughout.
3. Provide hooks in RequestMappingHandlerAdapter that subclasses can use
to programmatically modify the list of argument resolvers and return
value handlers, also adding new getters so subclasses can get access
to what they need for the override.
4. Make SessionStatus available through ModelAndViewContainer and
provide an argument resolver for it.
5. Init test and javadoc improvements.
When set to 'true' the flag makes RedirectAttributes the only way to add
attributes for a redirect thus ignoring the content of the default model
even if RedirectAttributes is not in the list of controller method args.
Separate client from server errors as much as possible in this order:
- raise MultipartException when resolving a multipart arg and the
request is not a multipart request (400)
- raise IllegalArgumentException when the arg type is MultipartFile
but the request is not of type MultipartHttpServletRequest (500)
- raise MissingServletRequestPartException when a MultipartResolver
is in use but the part is not found (400)
- detect presence of Servlet 3.0 before using standard multipart
parsing to find a request part or raise
IllegalArgumentException (500)
Unfortunately it is not always possible to separate client from
server errors mainly because the Servlet 3.0 API does not
distinguish between the case of 0 request parts vs multipart
processing not being configured.
Prior to this change, StandardServletEnvironment evaluated a
"jndiPropertySourceEnabled" flag to determine whether or not to add a
JndiPropertySource. Following the changes introduced in SPR-8490, there
is now no reason not to enable a JNDI property source by default. This
change eliminates the support for "jndiPropertySourceEnabled" and adds
a JndiPropertySource automatically.
Issue: SPR-8545, SPR-8490
Move JNDI_PROPERTY_SOURCE_ENABLED_FLAG from JndiPropertySource to
StandardServletEnvironment, as this is the only context in which the
constant makes sense.
Constructors have been added to both ContextLoader and
ContextLoaderListener to support instance-based programmatic
registration of listeners within ServletContainerInitializer
implementations in Servlet 3.0+ environments, and more particularly
when using Spring 3.1's WebApplicationInitializer SPI.
Issue: SPR-7672
ContextLoader and FrameworkServlet now use
AnnotationAwareOrderComparator to support @Order usage; previously
supported only implementation of the Ordered interface.
GenericWebApplicationContext now implements
ConfigurableWebApplicationContext in order to be compatible with
Framework/DispatcherServlet and ContextLoader/Listener, especially with
regard to changes in SPR-7672 that allow for programmatic use of these
types within Servlet 3.0+ environments. For the first time, it's now
reasonable to imagine injecting a GWAC into DispatcherServlet; the most
robust way to accommodate this possibility is for GWAC to implement
CWAC.
The implementation is in name only, allowing for interchangable use of
GWAC anywhere, for example, an XWAC could otherwise go. Methods such
as setConfigLocation will throw UnsupportedOperationException if the
configLocation value actually contains text. Other methods are
implemented as no-ops or to throw UOE as appropriate.
Issue: SPR-7672
WebApplicationInitializer provides a programmatic alternative to the
traditional WEB-INF/web.xml servlet container deployment descriptor
for Servlet API 3.0+ environments.
This is done by building atop the new ServletContainerInitializer
support in Servlet 3.0. See SpringServletContainerInitializer for
complete details. And see WebApplicationInitializer Javadoc for
typical usage examples.
Issue: SPR-7672
Arjen Poutsma
Rossen Stoyanchev
Sam Brannen
Chris Beams
Juergen Hoeller
David Syer