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-6847

In anticipation of substantive changes required to implement @Async
executor qualification, the following updates have been made to the
components and infrastructure supporting @Async functionality:

 - Fix trailing whitespace and indentation errors
 - Fix generics warnings
 - Add Javadoc where missing, update to use {@code} tags, etc.
 - Avoid NPE in AopUtils#canApply
 - Organize imports to follow conventions
 - Remove System.out.println statements from tests
 - Correct various punctuation and grammar problems

TransactionAspectUtils contains a number of methods useful in
retrieving a bean by type+qualifier. These methods are functionally
general-purpose save for the hard coding of PlatformTransactionManager
class literals throughout.

This commit generifies these methods and moves them into
BeanFactoryUtils primarily in anticipation of their use by async method
execution interceptors and aspects when performing lookups for qualified
executor beans e.g. via @Async("qualifier").

The public API of TransactionAspectUtils remains backward compatible;
all methods within have been deprecated, and all calls to those methods
throughout the framework refactored to use the new BeanFactoryUtils
variants instead.

The reference manual previously did not mention the applicability of
JSR-250 lifecycle annotations within the TestContext framework. The
lacking documentation here has lead to misunderstandings of the support
provided for @PostConstruct and @PreDestroy in test classes.

The testing chapter of the reference manual has therefore been updated
to explicitly define the limited support for these annotations.

Also introduced Jsr250LifecycleTests for empirical verification of the 
expected behavior.

Issue: SPR-4868

There is usually not need to put annotations on a WebDataBinder
argument in an `@InitBinder` method. However, the presence of any
annotation prevented the successful resolution of the argument.
This fix addresses the issue.

Issue: SPR-8946

Updated the "@Bean Lite Mode" section in order to properly document 
scoping and lifecycle semantics.

Also fleshed out the discussion of the non-applicability of 'inter-bean 
references' in lite mode.

Issue: SPR-9425

Introduced AtBeanLiteModeScopeTests integration tests to verify proper 
scoping of beans created in 'lite' mode.

Updated comments in TACCWithoutACTests to better reflect the runtime 
behavior for 'lite' @Bean methods.

Issue: SPR-9401

Revised the content in the @ContextConfiguration annotation section.

Issue: SPR-9401

* SPR-9249:
  Add value-type attrib to beans->map->entry element

Previously, the <value> subelement of a map <entry> allowed one to
specify the type of a specific map entry value. This patch allows a
value-type attribute as well, such that instead of the following
syntax

    <entry key="x-message-ttl">
        <value type="java.lang.Long">100</value>
    </entry>
    <entry key="x-ha-policy" value="all" />

one can now use the more concise form

    <entry key="x-message-ttl" value="100" value-type="java.lang.Long"/>
    <entry key="x-ha-policy" value="all"/>

The new value-type attribute may be used at the <map> level as well,
indicating that all elements are of the same type.

Appropriate tests have been added exercising value-type at the <map> and
<entry> levels.

Issue: SPR-9249

Commit 180c5b2e introduced 3.2 versions
of all spring-* schemas; this commit updates spring.schemas mapping
files to include these new versions.

Updated the testing chapter of the reference manual to refer to 
'annotated classes' instead of 'configuration classes' where 
appropriate.

Also revised the content and examples in the @ContextConfiguration 
annotation section, mentioned Gradle, and reformatted the entire text.

Issue: SPR-9401

Several test methods in RequestResponseBodyMethodProcessorTests
are currently annotated with @test(expected=…) and additionally contain:

    fail("Expected exception");

This combination is superfluous, and the unnecessary fail() invocations
have therefore been removed.

If true and there is no body => HttpMessageNotReadableException
If false and there is no body, the argument resolves to null.

Issue: SPR-9239

See the commit comments for:
https://github.com/SpringSource/spring-framework/commit/57307a0b2e5bce8f70d5deddf8df11d034dc8c5a

This commit also applies the change to pre-3.1 `@mvc` suppor classes.

Issue: SPR-6951

When URL decoding is turned off in AbstractHandlerMapping, the
extracted path variables are also not encoded. Turning off URL decoding
may be necessary for request mapping to work correctly when the path
may contain the (encoded) special character '/'. At the same time there
is no good reason not to leave path variables encoded. This change
ensures path variables are encoded when URL decoding is turned off.

Issue: SPR-9098

Updated all Javadoc in the Spring TestContext Framework (TCF) to explain
and refer to 'annotated classes' instead of 'configuration classes'.

Specifically, @ContextConfiguration now explicitly defines what is meant
by 'annotated classes', and various other classes now refer to this
definition. Otherwise, the term 'configuration class' has simply been
replaced with 'annotated class'.

Also deleted cross references to deprecated JUnit 3.8 classes and
formatted Javadoc in general for greater readability.

Issue: SPR-9401

Reordered inline comments so that they now apply to current
state of the code.

Added logger entry in testlog4j.properties to avoid console
warning.

Issue: SPR-9417

* SPR-5369:
  Fix circular placeholder prevention

A set of resolved placeholder references is used for circular
placeholder prevention. For complex property definitions this mechanism
would put property values with unresolved inner placeholder references
in the set, but would try to remove property values with placeholders
resolved, leaving the set in an invalid state and the mechanism broken.

This fix makes sure that the value that is put in the set is same one
that is removed from it, and by doing so avoids false positives in
reporting circular placeholders.

Issue: SPR-5369

* warnings:
  Fix compiler warnings

This patch fixes several compiler warnings that do not point to code
problems. Two kinds of warnings are fixed. First in a lot of cases
@SuppressWarnings("unchecked") is used although there are no unchecked
casts happening. This seems to be a leftover from when the code base
was on Java 1.4, now that the code base was moved to Java 1.5 these are
no longer necessary. Secondly there some places where the raw types of
List and Class are used where there wildcard types (List<?> and
Class<?>) would work just as well without causing any raw type warnings.

These changes are beneficial particularly when working in Eclipse or
other IDEs because it reduces 'noise', helping to isolate actual
potential problems in the code.

The following changes have been made:

 - remove @SuppressWarnings where no longer needed

 - use wildcard types instead of raw types where possible

* SPR-9203:
  Eliminate trailing whitespace in SpEL classes
  Support [] array ref syntax in SpEL T() construct

Prior to this change, SpEL would not allow the use of '[]' in
expressions like the following:

    T(foo.Bar[])

This commit updates TypeReference and InternalSpelExpressionParser to
support this syntax, avoiding the need for workarounds like:

    new foo.bar[0].class

Issue: SPR-9203

* SPR-8278:
  Fix compiler warnings in Constants/ConstantsTests
  Allow null params as advertised in Constants#toCode*

Even though the Javadoc for Constants#toCode and #toCodeForSuffix
specifies that a null value for the 'namePrefix' and 'nameSuffix'
parameters are respectively allowed, before this change passing a null
to either would result in a NullPointerException.

This change fixes constant name lookup for null values of these params
as if an empty string had been passed instead. This way of handling a
null value is consistent with the rest of Constants class API.

Issue: SPR-8278

* SPR-8360:
  Fix JibxMarshallerTests failing on Windows

Before this change JibxMarshallerTests would fail on Windows with an
error message explaining that JiBX compiler generated classes are not
found on the classpath for binding with name 'binding'. Tests would
execute well on Linux and OS X.

Actual root cause of this bug is found to be in JiBX 1.1.5 release that
is used to build Spring. The binding name can be explicitly specified in
JiBX binding file. If omitted, when generating classes the JiBX compiler
as fall-back mechanism tries to derive the binding name from the binding
file name. That logic had a bug which gets manifested when configured
binding file path has mixed Windows and *nix style file separators, as
in case of JibxMarshallerTests being executed on a Windows platform.

This commit resolves this issue by upgrading Spring's build from JiBX
1.1.5 to 1.2.3, as the bug mentioned was fixed in JiBX 1.2. See JIBX-441
for more details.

Issue: SPR-8360

* SPR-9123:
  Fix SpEL JavaBean compliance

Before this fix ReflectivePropertyAccessor was not able to find write
method for valid property name that has first character in lower case
and second character in upper case. Write method lookup would always
convert first character of property name to upper case which is not
compliant with JavaBean specification. As consequence this caused an
unwanted behavior in SpEL when obtaining values of expressions that
reference such JavaBean properties.

As of this change, write method lookup skips conversion of property
name first character to upper case when property name is longer than
one character and second character is in upper case. This also fixes
mentioned bug in SpEL value resolution.

Issue: SPR-9123

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

Previously, StringUtils#parseLocaleString would parse locale strings
having the same lowercase token for both language and country
incorrectly, e.g. 'tr_tr' would parse to 'tr_TR_tr' as opposed to the
expected 'tr_TR'.

This commit fixes this behavior by using using String#lastIndexOf
instead of String#indexOf when determining the location of the country
code token.

Issue: SPR-9420

Removed misleading mention of "configuration classes" in the
"@Bean Lite Mode" section.

Issue: SPR-9401

Updated the class-level JavaDoc for @Bean to better explain the
semantics of 'lite' mode.

Renamed "Configuration Class Lite Mode" to "@Bean Lite Mode".

Added discussion of @DependsOn to the class-level JavaDoc.

Issue: SPR-9401

* SPR-9342:
  Fix annotation search ending too early

In AnnotationUtils#findAnnotation(Method, Class), the search for a
method annotation fails if:

 - the original method does not have the annotation

 - an abstract superclass does not have an equivalent method declared

 - an interface implemented by the superclass has the method and
   the annotation -> this should be found, but is not!

This happens because the try-catch block in #findAnnotation is too wide:
cl.getDeclaredMethod() can throw NoSuchMethodException and skip the
'#searchOnInterfaces' call prematurely.

The try-catch block was made narrower to allow #searchOnInterfaces to
be called even if the abstract class does not have the method declared
at all.

Issue: SPR-9342

Overhauled the class-level JavaDoc in @Bean:

 - added h3 headers for greater clarity and readability
 - mentioned 'prototype' semantics for lite mode

Issue: SPR-9401