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
Introduced ContentNeogtiationStrategy for resolving the requested
media types from an incoming request. The available implementations
are based on path extension, request parameter, 'Accept' header,
and a fixed default content type. The logic for these implementations
is based on equivalent options, previously available only in the
ContentNegotiatingViewResolver.
Also in this commit is ContentNegotiationManager, the central class to
use when configuring content negotiation options. It accepts one or
more ContentNeogtiationStrategy instances and delegates to them.
The ContentNeogiationManager can now be used to configure the
following classes:
- RequestMappingHandlerMappingm
- RequestMappingHandlerAdapter
- ExceptionHandlerExceptionResolver
- ContentNegotiatingViewResolver
Issue: SPR-8410, SPR-8417, SPR-8418,SPR-8416, SPR-8419,SPR-7722
Commit aa415d7c0c introduced
JacksonObjectMapperFactoryBean and associated tests, but with Windows
(CRLF) line endings instead of the conventional Unix (LF) line endings.
This commit converts these files to LF endings using the handy
`dos2unix` utility.
Issue: SPR-9125
The BeanFactory makes it easier to configure a customized Jackson
ObjectMapper (for example enable/disable certain features).
This bean factory is usually used with
MappingJacksonHttpMessageConverter or MappingJacksonJsonView.
See JavaDoc for examples.
Issue: SPR-9125
Previously MediaType could only parse double-quoted parameters without
raising an IllegalArgumentException. Now parameters can also be
single-quoted.
Issue: SPR-8917
HttpStatus cannot be created with an unknown status code. If a server
returns a status code that's not in the HttpStatus enum values, an
IllegalArgumentException is raised. Rather than allowing it to
propagate as such, this change ensures the actual exception raised is
a RestClientException.
Issue: SPR-9406
Default HTTP error exceptions thrown from RestTemplate now include
response headers in addition to the response body. In particular, this
enables inspection of the Content-Type header allowing manual
deserialization of the response body without guessing as to the content
type.
- introduce HttpStatusCodeException#getResponseHeaders
- add constructor with headers param for HttpStatusCodeException,
HttpClientErrorException and HttpServerErrorException
- preserve exsisting constructor signatures
- mark HttpHeaders as Serializable
- generate new serialVersionUID where needed
Issue: SPR-7938
The following style updates have been made in anticipation of
substantive changes in subsequent commits:
- organize imports
- correct whitespace errors (leading spaces in code, tabs in Javadoc)
- wrap Javadoc at 90 chars; make imperative ("Return" vs. "Returns")
- use conventional constructor argument wrapping
A serialVersionUID has also been added to RestClientException and its
ResourceAccessException subclass for consistency with the rest of that
same exception hierarchy.
Issue: SPR-7938
This commit introduces three abstract WebApplicationInitializers, to be
used in the typical setup of a Spring-based web application.
- AbstractContextLoaderInitializer provides an abstract base class for
registering a ContextLoaderListener.
- AbstractDispatcherServletInitializer provides an abstract base class
for registering a DispatcherServlet, with an optional root context.
- AbstractAnnotationConfigDispatcherServletInitializer provides an
abstract base class for registering a DispatcherServlet and optional
ContextLoaderListener based on annotated (e.g. @Configuration)
classes.
Issue: SPR-9300
Previously, if the resolution of a ${...} placeholder resulted in a
valid URL for the location of a log4j properties/XML file, the URL
would ultimately be malformed by an unnecessary call to to
WebUtils#getRealPath.
The implementation of Log4jWebConfigurer#initLogging now eagerly
attempts SystemPropertyUtils#resolvePlaceholders before checking to see
if the location is a valid URL, and bypassing the call to
WebUtils#getRealPath if so.
Issue: SPR-9417
SPR-7591 introduced a java.nio.charset.Charset field within
HttpStatusCodeException. The former is non-serializable, thus by
extension the latter also became non-serializable.
Because the Charset field is only used for outputting the charset name
in HttpStatusCodeException#getResponseBodyAsString, it is reasonable to
store the value returned by Charset#name() instead of the actual Charset
object itself.
This commit refactors HttpStatusCodeException's responseCharset field to
be of type String instead of Charset and adds tests to prove that
HttpStatusCodeException objects are once again serializable as expected.
Issue: SPR-9273, SPR-7591
Before this fix the q-value of media types in the Accept header were
ignored when using the new RequestMappingHandlerAdapter in combination
with @ResponseBody and HttpMessageConverters.
Issue: SPR-9160
The ErrorsMethodArgumentResolver expects the preceding @ModelAttribute
in the controller method signature to be the last one added in the
model -- an assumption that can break if a model attribute is added
earlier (e.g. through a @ModelAttribute method) and more attributes
are added as well. This fix ensures when an @ModelAttribute is resolved
as a controller method argument it has the highest index in the model.
Issue: SPR-9378
Jackson serialization supports pretty printing. Usually it's enabled
by invoking ObjectMapper.configure(..), which is not convenient for
apps with XML configuration. The Jackson HttpMessageConverter and View
now both have a prettyPrint property.
A second more serious issue is documented here:
https://github.com/FasterXML/jackson-databind/issues/12
The workaround discussed at the above link has been implemented.
Issue: SPR-7201
Jackson 2 uses completely new package names and new maven artifact ids.
This change adds Jackson 2 as an optional dependency and also provides
MappingJackson2HttpMessageConverter and MappingJackson2JsonView for use
with the new version.
The MVC namespace and the MVC Java config detect and use
MappingJackson2HttpMessageConverter if Jackson 2 is present.
Otherwise if Jackson 1.x is present,
then MappingJacksonHttpMessageConverter is used.
Issue: SPR-9302
The fromUri method of UriComponentsBuilder used uri.getXxx() methods,
which decode the URI parts causing URI parsing issues. The same method
now uses uri.getRawXxx().
Issue: SPR-9317
When a controller returns a DeferredResult, the underlying async
request will eventually time out. Until now the default behavior was
to send a 503 (SERVICE_UNAVAILABLE). However, this is not desirable
in all cases. For example if waiting on an event, a timeout simply
means there is no new information to send.
To handle those cases a DeferredResult now accespts a timeout result
Object in its constructor. If the timeout occurs before the
DeferredResult is set, the timeout result provided to the constructor
is used instead.
Issue: SPR-8617
* Clarify semantics and behavior of AsyncWebRequest methods in most cases
making a best effort and not raising an exception if async processing
has completed for example due to a timeout. The startAsync() method is
still protected with various checks and will raise ISE under a number
of conditions.
* Return 503 (service unavailable) when requests time out.
* Logging improvements.
Issue: SPR-8517
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
* 3.1.x:
Demonstrate use of @Configuration as meta-annotation
Prune dead code from JmsTransactionManager#doBegin
Apply @Configuration BeanNameGenerator consistently
Improve @Configuration bean name discovery
Fix infinite recursion bug in nested @Configuration
Polish static imports
Minor fix in ServletResponseMethodArgumentResolver
extracted ResourceUtils.useCachesIfNecessary(URLConnection) method (SP
prepared for 3.1.1 release
CustomSQLExceptionTranslatorRegistry/Registrar etc
revised CustomSQLExceptionTranslatorRegistry/Registrar method naming
use custom InputStream traversal instead of a full byte array (SPR-911
PathMatchingResourcePatternResolver preserves caching for JNLP jar con
Resource "contentLength()" implementations work with OSGi bundle resou
fixed MethodInvokingJobDetailFactoryBean for compatibility with Quartz
fixed MethodInvokingJobDetailFactoryBean for compatibility with Quartz
* 3.1.x: (61 commits)
Compensate for changes in JDK 7 Introspector
Avoid 'type mismatch' errors in ExtendedBeanInfo
Polish ExtendedBeanInfo and tests
Infer AnnotationAttributes method return types
Minor fix in MVC reference doc chapter
Hibernate 4.1 etc
TypeDescriptor equals implementation accepts annotations in any order
"setBasenames" uses varargs now (for programmatic setup; SPR-9106)
@ActiveProfiles mechanism works with @ImportResource as well (SPR-8992
polishing
clarified Resource's "getFilename" method to consistently return null
substituteNamedParameters detects and unwraps SqlParameterValue object
Replace spaces with tabs
Consider security in ClassUtils#getMostSpecificMethod
Adding null check for username being null.
Improvements for registering custom SQL exception translators in app c
SPR-7680 Adding QueryTimeoutException to the DataAccessException hiera
Minor polish in WebMvcConfigurationSupport
Detect overridden boolean getters in ExtendedBeanInfo
Polish ExtendedBeanInfoTests
...
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
