In anticipation of substantive changes required to implement "initial
delay" support in the <task:scheduled> element and @Scheduled
annotation, the following updates have been made to the components and
infrastructure supporting scheduled task execution:

 - Fix code style violations
 - Fix compiler warnings
 - Add Javadoc where missing, update to use {@code} tags, etc.
 - Organize imports to follow conventions

Prove that Async#value is respected even when using @Async as a meta
annotation.

Issue: SPR-6847

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

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

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

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

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

Overhauled the class-level JavaDoc in @Bean:

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

Issue: SPR-9401

It is now advised that destroyMethod="shutdown" should be used
on @Bean methods returning an ExecutorService.

Issue: SPR-9280

Prior to this change, request-scoped components having
@Resource-injected dependencies caused a memory leak in
DefaultListableBeanFactory#dependenciesForBeanMap.

Consider the following example:

    @Component
    @Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS)
    public class MyComponent {

        @resource
        private HttpServletRequest request;

        // ...
    }

The bean name for "MyComponent" will end up being
'scopedTarget.myComponent', which will become a key in
the #dependenciesForBeanMap structure.

On the first request, the injected HttpServletRequest bean will be a
proxy and will internally have a bean name of the form
"$Proxy10@1a3a2a52". This name will be added to the Set value associated
with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap.

On the second request, the process will repeat, but the injected
HttpServletRequest will be a different proxy instance, thus having a
different identity hex string, e.g. "$Proxy10@5eba06ff". This name will
also be added to the Set value associated with the
'scopedTarget.myComponent' entry in #dependenciesForBeanMap, and this
is the source of the leak: a new entry is added to the set on each
request but should be added only once.

This commit fixes the leak by introducing caching to
CommonAnnotationBeanPostProcessor#ResourceElement similar to that already
present in AutowiredAnnotationBeanPostProcessor#AutowiredFieldElement
and #AutowiredMethodElement. Essentially, each ResourceElement instance
now tracks whether it has been created, caches the ultimate value to be
injected and returns it eagerly if necessary. Besides solving the memory
leak, this has the side effect of avoiding unnecessary proxy creation.

This fix also explains clearly why injection into request-scoped
components using @Autowired never suffered this memory leak: because the
correct caching was already in place. Because @resource is considerably
less-frequently used than @Autowired, and given that this particular
injection arrangement is relatively infrequent, it becomes
understandable how this bug has been present without being reported
since the introduction of @resource support in Spring 2.5: developers
were unlikely to encounter it in the first place; and if they did, the
leak was minor enough (adding strings to a Set), that it could
potentially go unnoticed indefinitely depending on request volumes and
available memory.

Issue: SPR-9176

Before this change there were numerous javadoc warnings being reported
while building Spring framework API.

This commit resolves most of the javadoc warnings, reducing the total
number from 265 to 103.

Issue: SPR-9113

Copy spring-*-3.1.xsd => spring-*-3.2.xsd; this commit introduces no
substantive changes, but rather prepares for them by creating a clean
baseline. All internal references to 3.1 schemas (e.g. spring-tool) have
also been updated.

With thanks to @abdull for pull request #55

Prior to this change, before a bean is created by EhCacheFactoryBean,
its #getObjectType would return only an Ehcache interface. This caused
unwanted wiring issues as described in the related JIRA issue.

This fix makes use of EhCacheFactoryBean's configuration to determine
the specific Ehcache object type even before it's created, such that
the container is provided with as much information as possible when
resolving dependencies. Nevertheless, users are advised to code to
the Ehcache interface.

Issue: SPR-7843

Changes in commit 41ade68b introduced
a regression causing all but the first location in the
@PropertySource#value array to be ignored during ${...} placeholder
resolution. This change ensures that all locations are processed and
replaced as expected.

Issue: SPR-9133, SPR-9127

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