From a programming model perspective, @RequestMapping methods now
support two new return value types:
* java.util.concurrent.Callable - used by Spring MVC to obtain the
return value asynchronously in a separate thread managed transparently
by Spring MVC on behalf of the application.
* org.springframework.web.context.request.async.DeferredResult - used
by the application to produce the return value asynchronously in a
separate thread of its own choosing.
The high-level idea is that whatever value a controller normally
returns, it can now provide it asynchronously, through a Callable or
through a DeferredResult, with all remaining processing --
@ResponseBody, view resolution, etc, working just the same but
completed outside the main request thread.
From an SPI perspective, there are several new types:
* AsyncExecutionChain - the central class for managing async request
processing through a sequence of Callable instances each representing
work required to complete request processing asynchronously.
* AsyncWebRequest - provides methods for starting, completing, and
configuring async request processing.
* StandardServletAsyncWebRequest - Servlet 3 based implementation.
* AsyncExecutionChainRunnable - the Runnable used for async request
execution.
All spring-web and spring-webmvc Filter implementations have been
updated to participate in async request execution.
The open-session-in-view Filter and interceptors implementations in
spring-orm will be updated in a separate pull request.
Issue: SPR-8517
The new @MVC support classes select a HandlerMethodArgumentResolver
and a HandlerMethodReturnValueHandler statically, i.e. based on
the signature of the method, which means that a controller method
can't declare a more general return type like Object but actually
return a more specific one, e.g. String vs RedirectView, and
expect the right handler to be used.
The fix ensures that a HandlerMethodReturnValueHandler is selected
based on the actual return value type, which is something that was
supported with the old @MVC support classes. One consequence
of the change is the selected HandlerMethodReturnValueHandler can
no longer be cached but that matches the behavior of the old
@MVC support classes.
Issues: SPR-9218
Previously 'Content-Disposition' was passed to Part.getHeader(String).
However the Javadoc for that method specifies the header should be
case insensitive. Note that the JavaDoc in tomcat-servlet-api doesn't
mention this. It can only be found in the official api JavaDoc:
http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/
Issue: SPR-9149
Before this fix MultipartResolver javadoc mentioned that there is only
one concrete implementation included in Spring. This was true as of
Spring 2.5 but Spring 3.1 added another one, Servlet 3.0 Part API based
implementation.
This fix changes MultipartResolver javadoc so that the other one,
StandardServletMultipartResolver implementation, gets also listed.
Changed javadoc mentions also as of which version does Spring bundle
two MultipartResolver implementations.
Issue: SPR-5984
Each of these tests began failing during the Gradle build porting
process. None seem severe, many are likely due to classpath issues.
In the case of TestNG support, this needs to be added to the Gradle
build in order to execute these tests. See SPR-8116.txt
This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.
Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example
$ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history up until the renaming event, where
$ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history for all changes to the file, before and after the
renaming.
See http://chrisbeams.com/git-diff-across-renamed-directories
Rossen Stoyanchev
Stevo Slavic
Chris Beams