Previously CallableProcessingInterceptor and
DeferredResultProcessingInterceptor did not have support for capturing
the state of the original Thread just prior to processing. This made it
difficult to transfer the state of one Thread (i.e. ThreadLocal) to the
Thread used to process the Callable.
This commit adds a new method to CallableProcessingInterceptor and
DeferredResultProcessingInterceptor named beforeConcurrentHandling
which will be invoked on the original Thread used to submit the Callable
or DeferredResult. This means the state of the original Thread can be
captured in beforeConcurrentHandling and transfered to the new Thread
in preProcess.
Issue: SPR-10052
The name MvcAsyncTask is misleading because the class is part of Spring
Web as apposed to Spring MVC. This is also inconsistent with the other
async classes which use Web instead of Mvc.
This commit changes MvcAsyncTask to WebAsyncTask making it more
consistent with the jar it is found in and the other async classes.
Issue: SPR-10051
Since web applications declaring a Servlet 2.3 web.xml become really rare now, we're finally deprecating Spring's own ExpressionEvaluationUtils class. As a consequence, we're also setting "springJspExpressionSupport" to false by default, avoiding the potential double EL evaluation problem on pre-Servlet-3.0 containers.
Issue: SPR-5308
The change to support generic @RequestBody arguments introduced in
3.2 M2 also introduced a regression in reading arguments that are
type variables. This change fixes the issue.
Issue: SPR-9964
This is more specific exception raised instead of RestClientException
when the raw HTTP status code received from the server is not one of
the HttpStatus enum values.
Issue: SPR-9406
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.
Prior to this commit the MockHttpServletRequest constructor chain set
the preferred local to Locale.ENGLISH. Furthermore, it was possible to
add additional preferred locales "in front" of ENGLISH; however, it was
not possible to delete ENGLISH from the list of preferred locales.
This commit documents the fact that ENGLISH is the default preferred
locale and makes it possible to set the list of preferred locales via a
new setPreferredLocales(List<Locale> locales) method.
Issue: SPR-9724
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
Some servlet containers (iPlanet) parse the Accept header and return
multiple values from request.getHeader("Accept"). The HttpHeaders
getAccept method has been updated to accommodate that hopefully
without causing any other issues.
The extra functionality is in effect only if we find only one
MediaType and there is more than one value for the 'Accept' header.
Issue: SPR-9655
Previously UriComponentsBuilder used a regular expression for parsing
query name-value pairs where both name and value were expected to not
contain neither '&', not '='. The idea is that the presence of reserved
characters makes it impossible to guess correctly how to parse the
query string (e.g. a=b&c).
This change relaxes the constraint on query param values, allowing them
to contain '='. In effect '&' is the ultimate separator of name-value
pairs, and any '=' in values is ignored. For example "q=1USD=?EUR" is
interpreted as "q equals '1USD=?EUR'".
Issue: SPR-9832
An additional update (after the last commit) of the "includes" and
"isCompatibleWith" methods of MediaType to accomodate wildcards
in media types with a suffix.
Issue: SPR-9841
The "includes" and "isCompatibleWith" methods of MediaType take into
account media types with suffices (e.g. application/soap+xml) including
wildcards with suffices (e.g. application/*+xml). However before this
change, the isWildcardSubtype() method returned true only for subtype
"*". Now a media type such as application/*+xml is also recognized as
having a wildcard subtype.
Issue: SPR-9841
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
Before this commit, UriComponentsBuilder did not handle opaque URIs at
all. After this commit it does.
Support is introduced by making UriComponents an abstract base class,
and having two concrete subclasses: HierarchicalUriComponents and
OpaqueUriComponents. The former is more or less the same as the old
UriComponents class.
Issue: SPR-9798
This new converter uses StringHttpMessageConverter internally combined
with a ConversionService for converting String content to and from the
target object type.
Issue: SPR-9738
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.
Class#getDeclaredMembers returns arbitrary results under JDK7. This
results in non-deterministic execution of JUnit test methods, often
revealing unintended dependencies between methods that rely on a
specific order to succeed.
JUnit 4.11 contains support for predictable test ordering [1], but at
the time of this commit, JUnit 4.11 has not yet been released.
Therefore we are testing against a snapshot version [2], which has been
uploaded to repo.springsource.org [3] for easy access. Note that this
artifact may be removed when JUnit 4.11 goes GA.
- Care has been taken to ensure that spring-test's compile-time
dependency on JUnit remains at 4.10. This means that the spring-test
pom.xml will continue to have an optional <dependency> on JUnit
4.10, instead of the 4.11 snapshot.
- For reasons not fully understood, the upgrade to the 4.11 snapshot
of junit-dep caused NoSuchMethodErrors around certain Hamcrest
types, particularly CoreMatchers and Matchers. import statements
have been updated accordingly throughout affected test cases.
- Runtime errors also occurred around uses of JUnit @Rule and
ExpectedException. These have been reverted to use simpler
mechanisms like @Test(expected) in the meantime.
- Some test methods with order-based dependencies on one another have
been renamed in order to fall in line with JUnit 4.11's new method
ordering (as opposed to actually fixing the inter-test
dependencies). In other areas, the fix was as simple as adding a
tearDown method and cleaning up state.
- For no apparent reason, the timeout in AspectJAutoProxyCreatorTests'
testAspectsAndAdvisorNotAppliedToPrototypeIsFastEnough method begins
to be exceeded. Prior to this commit the timeout value was 3000 ms;
on the CI server under Linux/JDK6 and JDK7, the test begins taking
anywhere from 3500-5500 ms with this commit. It is presumed that
this is an incidental artifact of the upgrade to JUnit 4.11. In any
case, there are no changes to src/main in this commit, so this
should not actually represent a performance risk for Spring
Framework users. The timeout has been increased to 6000 ms to
accommodate this situation.
[1]: https://github.com/KentBeck/junit/pull/293
[2]: https://github.com/downloads/KentBeck/junit/junit-dep-4.11-SNAPSHOT-20120805-1225.jar
[3]: https://repo.springsource.org/simple/ext-release-local/junit/junit-dep/4.11.20120805.1225
Issue: SPR-9783
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
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
This change makes it possible to use the RestTemplate to read an HTTP
response into a target generic type object. The RestTemplate has three
new exchange(...) methods that accept ParameterizedTypeReference -- a
new class that enables capturing and passing generic type info.
See the Javadoc of the three new methods in RestOperations for a
short example.
To support this feature, the HttpMessageConverter is now extended by
GenericHttpMessageConverter, which adds a method for reading an
HttpInputMessage to a specific generic type. The new interface
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-7023
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
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
Currently the getNamedDispatcher(String) method of MockServletContext
always returns null. This poses a problem in certain testing scenarios
since one would always expect at least a default Servlet to be present.
This is specifically important for web application tests that involve
the DefaultServletHttpRequestHandler which attempts to forward to the
default Servlet after retrieving it by name. Furthermore, there is no
way to register a named RequestDispatcher with the MockServletContext.
This commit addresses these issues by introducing the following in
MockServletContext.
- a new defaultServletName property for configuring the name of the
default Servlet, which defaults to "default"
- named RequestDispatchers can be registered and unregistered
- a MockRequestDispatcher is registered for the "default" Servlet
automatically in the constructor
- when the defaultServletName property is set to a new value the
the current default RequestDispatcher is unregistered and replaced
with a MockRequestDispatcher for the new defaultServletName
Issue: SPR-9587
After this change each call stack level pushes and pops an async
Callable to ensure the AsyncExecutionChain is in sync with the
call stack. Before this change, a controller returning a "forward:"
prefixed string caused the AsyncExecutionChain to contain a
extra Callables that did not match the actual call stack.
Issue: SPR-9611
The HTTP PATCH method is now supported whereever HTTP methods are used.
Annotated controllers can be mapped to RequestMethod.PATCH.
On the client side the RestTemplate execute(..) and exchange(..)
methods can be used with HttpMethod.PATCH. In terms of HTTP client
libraries, Apache HttpComponents HttpClient version 4.2 or later is
required (see HTTPCLIENT-1191). The JDK HttpURLConnection does not
support the HTTP PATCH method.
Issue: SPR-7985
