Fix serialization warnings by applying @SuppressWarnings("serial")
when appropriate.

In certain cases and for unknown reasons, a correctly-placed
@SuppressWarnings("serial") annotation will fix the warning at the
javac level (i.e. the Gradle command-line), but will produce an
"unnecessary @SuppressWarnings" warning within Eclipse. In these
cases, a private static final serialVersionUID field has been added
with the default value of 1L.

Issue: SPR-10128

Issue: SPR-10127

  find . -type f -name "*.java" -or -name "*.aj" | \
    xargs perl -p -i -e "s/[ \t]*$//g" {} \;

Issue: SPR-10127

In particular, avoiding synchronized Sets and Maps wherever possible (preferring a ConcurrentHashMap even instead of a synchronized Set) and specifying appropriate ConcurrentHashMap initial capacities (even if we end up choosing 16).

 - Support external Javadoc links using Gradle's javadoc.options.links

 - Fix all other Javadoc warnings, such as typos, references to
   non-existent (or no longer existent) types and members, etc,
   including changes related to the Quartz 2.0 upgrade (SPR-8275) and
   adding the HTTP PATCH method (SPR-7985).

 - Suppress all output for project-level `javadoc` tasks in order to
   hide false-negative warnings about cross-module @see and @link
   references (e.g. spring-core having a @see reference to spring-web).
   Use the `--info` (-i) flag to gradle at any time to see project-level
   javadoc warnings without running the entire `api` task. e.g.
   `gradle :spring-core:javadoc -i`

 - Favor root project level `api` task for detection of legitimate
   Javadoc warnings. There are now zero Javadoc warnings across the
   entirety of spring-framework. Goal: keep it that way.

 - Remove all @link and @see references to types and members that exist
   only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+
   respectively. This is necessary because only one version of each of
   these dependencies can be present on the global `api` javadoc task's
   classpath. To that end, the `api` task classpath has now been
   customized to ensure that the Servlet 3 API and Hibernate Core 4 jars
   have precedence.

 - SPR-8896 replaced our dependency on aspectjrt with a dependency on
   aspectjweaver, which is fine from a POM point of view, but causes
   a spurious warning to be emitted from the ant iajc task that it
   "cannot find aspectjrt on the classpath" - even though aspectjweaver
   is perfectly sufficient. In the name of keeping the console quiet, a
   new `rt` configuration has been added, and aspectjrt added as a
   dependency to it. In turn, configurations.rt.asPath is appended to
   the iajc classpath during both compileJava and compileTestJava for
   spring-aspects.

Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896

Issue: SPR-8116, SPR-10074

Documented why static nested test cases in the spring-test module are
ignored, explaining that such "TestCase classes are run manually by the
enclosing test class". Prior to the migration to Gradle (i.e., with
Spring Build), these tests would not have been picked up by the test
suite since they end with a "TestCase" suffix instead of "Test" or
"Tests".

Re-enabled HibernateMultiEntityManagerFactoryIntegrationTests.

For the remaining tests that were disabled as a result of the migration
to Gradle, comments have been added to the @Ignore declarations.

Issue: SPR-8116, SPR-9398

Transaction timeouts for JPA translate to "javax.persistence.query.timeout" only (for EclipseLink compatibility)

Issue: SPR-10068

Previously when running the tests for spring-web, spring-webmvc,
spring-test-mvc, and spring-orm there were possible collissions in the
classpath due to the fact that each had its own copy of the web.Mock*
classes in it. This causes uncertainty for which class the code was
running against. Furthermore, the maintance of keeping the copies up to
date was tedious.

Now there are two copies of the web.Mock* classes. The ones that exist
in spring-test main sources and a copy that supports servlet 3 within
spring-web test sources. The copy in spring-web test sources has been
moved to a new package to avoid having the classes exist twice on the
classpath within Eclipse.

Officially deprecated Apache iBATIS support in favor of native Spring support in Mybatis (http://code.google.com/p/mybatis/)

Previously reflection was required when interacting with Hibernate 4 in
order to support both Hibernate 3 and Hibernate 4 since there were
non-passive changes in the APIs. Now that the Spring build uses Gradle
it is trivial to support multiple Hibernate versions.

This commit removes the reflection usage in orm.hibernate4.* by
creating a spring-orm-hibernate4 module that uses
gradle/merge-artifacts.gradle to build a single artifact but keep
distinct classpaths.

Issue: SPR-10039

Issue: SPR-9978

Issue: SPR-9914

Issue: SPR-9883

OncePerRequestFilter now allows sub-classes to choose whether they
should ever get involved in processing an error dispatch.

Issue: SPR-9895

Issue: SPR-9895

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

Issue: SPR-9797

Issue: SPR-9797

Issue: SPR-9846

A reset method now allows it to be invoked more than once each time
storing the request and response with which it was invoked.

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.

Added handler argument to the signature of
AsyncHandlerInterceptor.afterConcurrentHandlingStarted(..).

Renamed AsyncWebUtils to WebAsyncUtils.

Issue: SPR-9741

This change fixes a cyclical package dependency.

The change also improves the implementation of
WebAsyncManager.hasConcurrentResult() following the resolution of
Apache issue id=53632 and the release of Apache Tomcat 7.0.30 that
contains the fix.

This commit adds the ability to allow the MockFilterChain to invoke
a List of Filter's and/or a Servlet.

Issue: SPR-9745

Issue: SPR-9433

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

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