Prior to this change,
FrameworkServlet#configureAndRefreshWebApplicationContext called
#postProcessWebApplicationContext(wac) and #applyInitializers(wac)
prior to #refresh, but because servlet-based property source stubs were
not replaced until #refresh, any post-processing or initialization
routines could not benefit from accessing the Environment to retrieve
properties from the ServletContext or ServletConfig.
The workaround to this problem is detailed in SPR-9610 - the user simply
needed to call WebApplicationContextUtils#initServletPropertySources
manually within their ApplicationContextInitializer (or overridden
#postProcessWebApplicationContext method)
This commit ensures that
FrameworkServlet#configureAndRefreshWebApplicationContext calls
WebApplicationContextUtils#initServletPropertySources eagerly, prior to
invoking #postProcessWebApplicationContext and #applyInitializers.
Related Javadoc has also been updated throughout to clarify the behavior
of #initServletPropertySources, when it can be called and what the
effects are, etc.
Note also that a reproduction issue was added to demonstrate the problem
and verify its resolution [1].
[1]: https://github.com/SpringSource/spring-framework-issues/tree/master/SPR-9610
Issue: SPR-9610
The original commit c9b7b1 ensured the ability to read parameterized
type @RequestBody arguments via GenericHttpMessageConverter (e.g.
application/json and List<String>). However, it also affected the
ability to read @RequestBody arguments that happen are parameterized
but aren't treated as such (e.g. application/x-www-form-urlencoded and
MultiValueMap<String, String>). This commit corrects the issue.
Issue: SPR-9570
For @RequestBody(required=false), it is not sufficient to check if the
InputStream is null. This change reads the first byte of the request
InputStream to determine if the request body is empty or not.
If the InputStream implementation supports mark(int) and reset(), then
we use those. Otherwise we use PushbackInputStream to read and unread
the first byte.
All of this is done only if the required flag of @RequestBody is set
to "false" (default is "true").
Issue: SPR-9942
The servlet spec recommends removing path parameters from the
contextPath, servletPath, and pathInfo but not from the requestURI.
This poses a challenge for the UrlPathHelper, which determines the
lookup path by comparing the above.
This change introduces a method that matches the requestURI to the
contextPath and servletPath ignoring path parameters (i.e. matrix
variables) for comparison purposes while also preserving them in the
resulting lookup path.
The MVC namespace and the MVC Java config now allow configuring
CallableProcessingInterceptor and DeferredResultProcessingInterceptor
instances.
Issue: SPR-9914
New afterTimeout and afterCompletion callbacks
afterTimeout can provide a concurrent result to be used instead of the
one that could not be set or returned on time
Interceptor exceptions cause async processing to resume treating the
exception as the concurrent result
Adapter classes for convenient implementation of the interfaces
Issue: SPR-9914
Before this change View implementations set the response content type
to the fixed value they were configured with.
This change makes it possible to configure a View implementation with
a more general media type, e.g. "application/*+xml", and then set the
response type to the more specific requested media type, e.g.
"application/vnd.example-v1+xml".
Issue: SPR-9807.
This change ensures that when the Accept and the Producible media types
are equally specific, we use the one from the Accept header, which may
for example carry a different charset.
Aside from minor polishing, this change sets the "systemProperties" and "systemEnvironment" beans at each factory level as well.
Issue: SPR-9756
Issue: SPR-9764
Caching of resovled exceptions introduced in SPR-7703 also introduced a
side effect whereby if exactly one exception was previously cached, any
other exception would appear as a match to the previously matched
@ExceptionHandler method.
This change ensures use of a fresh map when determining matching
@ExceptionHandler methods while also updating the cache.
Issue: SPR-9209
Before this change the PathExtensionContentNegotiationStrategy accessed
the ServletContext via request.getServletContext, which is Servlet 3
specific. To work around it, there is now a Servlet-specific sub-class
that accepts a ServletContext as a constructor argument.
The ContentNegotiationManagerFactoryBean is now ServletContextAware and
if it has a ServletContext it creates the Servlet-specific sub-class
of PathExtensionContentNegotiationStrategy.
The ContentNegotiationManagerFactoryBean is now also used in several
places internally -- MVC namespace, MVC Java config, and the
ContentNegotiatingViewResolver -- to reduce duplication.
Issue: SPR-9826
The RequestMethodsRequestCondition is now protected against HTTP
request method values not present in the RequestMethod enumeration
(e.g. PROPFIND).
Issue: SPR-9815
This change introduces two new interceptors with callback methods
for concurrent request handling. These interfaces are
CallableProcessingInterceptor and DeferredResultProcessingInterceptor.
Unlike a HandlerInterceptor, and its AsyncHandlerInterceptor sub-type,
which intercepts the invocation of a handler in he main request
processing thread, the two new interfaces are aimed at intercepting the
asynchronous execution of a Callable or a DeferredResult.
This allows for the registration of thread initialization logic in the
case of Callable executed with an AsyncTaskExecutor, or for centralized
tracking of the completion and/or expiration of a DeferredResult.
DefaultHandlerExceptionResolver and ResponseEntityExceptionHandler now
both set the "javax.servlet.error.exception" request attribute to the
raised exception, allowing custom error pages configured via web.xml.
Issue: SPR-9653
While HandlerMethod instances are cached for lookup purposes, a new
ServletInvocableHandlerMethod instance has to be created prior to each
invocation since handlers may have non-singleton scope semantics.
This change reduces the overhead of creating per request instances
by using a logger with a fixed name rather than relying on getClass()
and also by copying introspected method parameters from the cached
HandlerMethod instance.
Issue: SPR-9747, SPR-9748
This change fixes a cyclical package dependency.
The change also improves the implementation of
WebAsyncManager.hasConcurrentResult() following the resolution of
Apache issue id=53632 and the release of Apache Tomcat 7.0.30 that
contains the fix.
This commit avoids eager creation of Environment instances, favoring
delegation of already existing Environment objects where possible. For
example, FrameworkServlet creates an ApplicationContext; both require
a StandardServletEnvironment instance, and prior to this change, two
instances were created where one would suffice - indeed these two
instances may reasonably be expected to be the same. Now, the
FrameworkServlet defers creation of its Environment, allowing users to
supply a custom instance via its #setEnvironment method (e.g. within a
WebApplicationInitializer); the FrameworkServlet then takes care to
delegate that instance to the ApplicationContext created
in #createWebApplicationContext.
This behavior produces more consistent behavior with regard to
delegation of the environment, saves unnecessary cycles by avoiding
needless instantiation and calls to methods like
StandardServletEnvironment#initPropertySources and leads to better
logging output, as the user sees only one Environment created and
initialized when working with the FrameworkServlet/DispatcherServlet.
This commit also mirrors these changes across the corresponding
Portlet* classes.
Issue: SPR-9763
The AbstractDispatcherServletInitializer now provides support for
the registration of filters to be mapped to the DispatcherServlet.
It also sets the asyncSupported flag by default on the
DispatcherServlet and all registered filters.
Issue: SPR-9696
A new @MatrixVariable annotation allows injecting matrix variables
into @RequestMapping methods. The matrix variables may appear in any
path segment and should be wrapped in a URI template for request
mapping purposes to ensure request matching is not affected by the
order or the presence/absence of such variables. The @MatrixVariable
annotation has an optional "pathVar" attribute that can be used to
refer to the URI template where a matrix variable is located.
Previously, ";" (semicolon) delimited content was removed from the
path used for request mapping purposes. To preserve backwards
compatibility that continues to be the case (except for the MVC
namespace and Java config) and may be changed by setting the
"removeSemicolonContent" property of RequestMappingHandlerMapping to
"false". Applications using the MVC namespace and Java config do not
need to do anything further to extract and use matrix variables.
Issue: SPR-5499, SPR-7818
Rename ExceptionHandlerSupport to ResponseEntityExceptionHandler and
emphasize the contrast to DefaultHandlerExceptionResovler -- i.e.
one returns a ResponseEntity and relies on message converters while
the other returns a ModelAndView and relies on view resolution.
Issue: SPR-9290
This change makes it possible to declare an @RequestBody argument with
a generic type (e.g. List<Foo>). If a GenericHttpMessageConverter
implementation supports the method argument, then the request will be
converted to the apropiate target type.
The new GenericHttpMessageConverter is implemented by the
MappingJacksonHttpMessageConverter and also by a new
Jaxb2CollectionHttpMessageConverter that can read read a generic
Collection where the generic type is a JAXB type annotated with
@XmlRootElement or @XmlType.
Issue: SPR-9570
The target parameters for a FlashMap must be decoded to be able to
match them to the parameters of incoming requests given that the
HttpServletRequest returns decoded request parameters.
SPR-9657
An @RequestBody or an @RequestPart argument can now be followed by an
Errors/BindingResult argument making it possible to handle validation
errors (as a result of an @Valid annotation) locally within the
@RequestMapping method.
Issue: SPR-7114
The new class is functionally equivalent to the
DefaultHandlerExceptionResolver (i.e. it translates Spring MVC
exceptions to various status codes) but uses an @ExceptionHandler
returning a ResponseEntity<Object>, which means it can be customized to
write error content to the body of the response.
Issue: SPR-9290
The MVC Java config method to implement is
WebMvcConfigurer.configureAsyncSupport(AsyncSupportConfigurer)
The MVC namespace element is:
<mvc:annotation-driven>
<mvc:async-support default-timeout="2500" task-executor="myExecutor" />
</mvc:annotation-driven>
Issue: SPR-9694
Methods returning DeferredResult can now specify a timeout value
through constructor arg while methods returning a Callable can wrap it
in an AsyncTask that also accepts a timeout and a specific task
executor.
Issue: SPR-9399
DeferredResult now has a setErrorResult method that can be set to an
Exception or an error object, error view, etc.
The new isSetOrExpired() method can be used to check pro-actively if
the DeferredResult is still usable or not.
The setDeferredResultHandler method is now public so tests may use it.
Issue: SPR-9690, SPR-9689
Classes with this annotation can contain @ExceptionHandler,
@InitBinder, and @ModelAttribute methods that apply to all controllers.
The new annotation is also a component annotation allowing
implementations to be discovered through component scanning.
Issue: SPR-9112
As a result of the refactoring, the AsyncContext dispatch mechanism is
used much more centrally. Effectively every asynchronously processed
request involves one initial (container) thread, a second thread to
produce the handler return value asynchronously, and a third thread
as a result of a dispatch back to the container to resume processing
of the asynchronous resuilt.
Other updates include the addition of a MockAsyncContext and support
of related request method in the test packages of spring-web and
spring-webmvc. Also an upgrade of a Jetty test dependency required
to make tests pass.
Issue: SPR-9433
Usually this request attribute is set for all sub-classes of
AbstractUrlHandlerMapping and therefore whenever
AnnotationMethodHandlerAdapter is used. However, having a
default value to fall back on in AnnotationMethodHandlerAdapter
is still appropriate in general and also considering the Javadoc
of HandlerMapping.INTROSPECT_TYPE_LEVEL_MAPPING.
Issue: SPR-9629
The MVC Java config and the MVC namespace now support options to
configure content negotiation. By default both support checking path
extensions first and the "Accept" header second. For path extensions
.json, .xml, .atom, and .rss are recognized out of the box if the
Jackson, JAXB2, or Rome libraries are available. The ServletContext
and the Java Activation Framework may be used as fallback options
for path extension lookups.
Issue: SPR-8420
