Prior to this change, Spring's @Async annotation support was tied to a
single AsyncTaskExecutor bean, meaning that all methods marked with
@Async were forced to use the same executor. This is an undesirable
limitation, given that certain methods may have different priorities,
etc. This leads to the need to (optionally) qualify which executor
should handle each method.
This is similar to the way that Spring's @Transactional annotation was
originally tied to a single PlatformTransactionManager, but in Spring
3.0 was enhanced to allow for a qualifier via the #value attribute, e.g.
@Transactional(ptm1)
public void m() { ... }
where ptm1 is either the name of a PlatformTransactionManager bean or
a qualifier value associated with a PlatformTransactionManager bean,
e.g. via the <qualifier> element in XML or the @Qualifier annotation.
This commit introduces the same approach to @Async and its relationship
to underlying executor beans. As always, the following syntax remains
supported
@Async
public void m() { ... }
indicating that calls to #m will be delegated to the default executor,
i.e. the executor provided to
<task:annotation-driven executor=.../>
or the executor specified when authoring a @Configuration class that
implements AsyncConfigurer and its #getAsyncExecutor method.
However, it now also possible to qualify which executor should be used
on a method-by-method basis, e.g.
@Async(e1)
public void m() { ... }
indicating that calls to #m will be delegated to the executor bean
named or otherwise qualified as e1. Unlike the default executor
which is specified up front at configuration time as described above,
the e1 executor bean is looked up within the container on the first
execution of #m and then cached in association with that method for the
lifetime of the container.
Class-level use of Async#value behaves as expected, indicating that all
methods within the annotated class should be executed with the named
executor. In the case of both method- and class-level annotations, any
method-level #value overrides any class level #value.
This commit introduces the following major changes:
- Add @Async#value attribute for executor qualification
- Introduce AsyncExecutionAspectSupport as a common base class for
both MethodInterceptor- and AspectJ-based async aspects. This base
class provides common structure for specifying the default executor
(#setExecutor) as well as logic for determining (and caching) which
executor should execute a given method (#determineAsyncExecutor) and
an abstract method to allow subclasses to provide specific strategies
for executor qualification (#getExecutorQualifier).
- Introduce AnnotationAsyncExecutionInterceptor as a specialization of
the existing AsyncExecutionInterceptor to allow for introspection of
the @Async annotation and its #value attribute for a given method.
Note that this new subclass was necessary for packaging reasons -
the original AsyncExecutionInterceptor lives in
org.springframework.aop and therefore does not have visibility to
the @Async annotation in org.springframework.scheduling.annotation.
This new subclass replaces usage of AsyncExecutionInterceptor
throughout the framework, though the latter remains usable and
undeprecated for compatibility with any existing third-party
extensions.
- Add documentation to spring-task-3.2.xsd and reference manual
explaining @Async executor qualification
- Add tests covering all new functionality
Note that the public API of all affected components remains backward-
compatible.
Issue: SPR-9443
Backport-Issue: SPR-6847
Backport-Commit: ed0576c181
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
Backport-Issue: SPR-9549
Backport-Commit: a33fe6fa0a
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
Backport-Issue: SPR-9502
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
Backport-Issue: SPR-9168
Backport-Commit: 982cb2f258
The MappingJacksonHttpMessageConverter now catches all IOException
types raised while reading JSON and translates them into
HttpMessageNotReadableException.
Issue: SPR-9238
Backport-Issue: SPR-9397
Backport-Commit: 816c1f47a4
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
Backport-Issue: SPR-9507
Backport-Commit: e63ca04fdb
Invalid Content-Type or Accept header values previously resulted in the
IllegalArgumentException getting propagated. After this change such
errors are detected and generally treated as a "no match", which
may for example result in a 406 in the case of the Accept header.
Issue: SPR-9142
Backport-Issue: SPR-9148
Backport-Commit: ca8b98e947
The contents of this file could be problematic as they were generated
by spring-build with "org.springframework.core.jar" EBR-style naming,
but this naming is incorrect when dealing with Maven-central style
artifacts, e.g. spring-core.jar.
While a well-formed INDEX.LIST may speed up classloading, the simplest
solution to the issues listed below is simply to eliminate the file.
This also means consistent treatment across 3.1.x and 3.2.x artifacts,
as the new Gradle build in 3.2.x does not create these index files.
Issue: SPR-6383, SPR-9208
ServletServerHttpRequest now falls back on the contentType and the
the characterEncoding of the ServletRequest, if the headers of the
incoming request don't specify one. Similary ServletServerHttpResponse
sets the contentType and the characterEncoding of the ServletResponse
if not already set.
This allows using the CharacterEncodingFilter to set a character
encoding where the request doesn't specify one and have it be used
in HttpMessageConverter's.
SPR-9096
Although the reference documentation listed the new @MVC support
classes and their benefits, it did not explicitly mention a few
use cases that are no longer supported. There is now a specific
section on the new support classes listing exactly what is not
supported.
Similary the @RequestMapping annotation never refered explicitly
to the existence of old and new support and never made it clear
exactly what the differences are.
Both have not been corrected.
SPR-9063, SPR-9042
A list of "known" session attributes (listed in @SessionAttributes)
was gradually built as attributes get added to the model. In a
failover scenario that knowledge is lost causing session attributes
to be potentially re-initialized via @ModelAttribute methods.
With this change @SessionAttributes listed by name are immediately
added to he list of "known" session attributes thus this knowledge
is not lost after a failover. Attributes listed by type however
still must be discovered as they get added to the model.
The "default" FlashMapManager implementation added in 3.1 was invoked
after the redirect, which is too late in cases where the HTTP session
has not been yet been created since as the response is committed.
This change corrects the issue and makes other improvements to the
FlashMapManager implementation such as extracting a base
AbstractFlashMapManager class and making it easier for other
implementations to be added (for example cookie-based).
A direct path match with incorrect HTTP request method was causing another
request mapping with a pattern and a correct HTTP method to be ignored.
The bug affects the new @MVC support classes
(i.e. RequestMappingHandlerMapping).
The AbstractHttpMessageConverter was using the requested Content-Type
rather than the actual response Content-Type to determine the length
of the content. This can lead to a problem when a controller returns
a ResponseEntity with a Content-Type header that ignores (overrides)
the requested Content-Type. The fix ensures that actual response
Content-Type is the one used both to write to the response and to
determine the length of the content.
The UriComponentsBuilder instance passed into the method is initialized
with current request information including host, scheme, port, context
path, and the servlet mapping's literal part.
Also added shortcut methods to buildAndExpand in UriComponentsBuilder.
Juergen Hoeller
Chris Beams
Rossen Stoyanchev
Arjen Poutsma
Costin Leau