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

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

The invalidate() method in MockHttpSession is currently implemented
incorrectly. According to the Servlet specification, the method should
throw an IllegalStateException if it is invoked on an already
invalidated session. However, invoking invalidate() on the same
MockHttpSession instance multiple times does not throw an exception.

This commits addresses this issue by checking the invalid field and
throwing an IllegalStateException if it has already been set to true.

Issue: SPR-9686

Classes with this annotation can contain @ExceptionHandler,
@InitBinder, and @ModelAttribute methods that apply to all controllers.
The new annotation is also a component annotation allowing
implementations to be discovered through component scanning.

Issue: SPR-9112

This commit polishes the exception message thrown by customizeContext()
for greater readability.

spring-core, spring-aop and spring-context each have compile-time
dependencies on classes in the aspectjweaver jar. Prior to this commit,
only spring-core declared an optional dependency on it; now all three
do.

Issue: SPR-9683

Historically spring-orm has had an optional dependency on spring-web,
primarily in support of OpenSessionInView functionality. This optional
dependency was inadvertently made required when porting the build to
Gradle. This commit simply reintroduces the optional setting.

Issue: SPR-9632

XStreamMarshaller now supports writing to OutputStreams and reading from
InputStreams directly, as opposed to wrapping streams in a
OutputStreamWriter or InputStreamReader.

Issue: SPR-9663

Prior to this change, the repackaged spring-asm and spring-cglib jars
were being included wholesale in the spring-core jar, whereas the
intention was to include the unzipped classfiles.

This change ensures that spring-asm and spring-cglib jars are unzipped
on the fly when creating the spring-core jar.

Issue: SPR-9669

ReflectionTestUtils.setField() implicitly calls toString() on the target
object when arguments for a call to Assert.notNull() are built. This can
have undesirable side effects, for example if the toString() invocation
results in a thrown exception or access to an external system (e.g., a
database).

This commit addresses this issue by inlining the Assert.notNull() code,
thereby avoiding accidental invocation of toString() on a non-null
target.

Issue: SPR-9571

The default set of TestExecutionListeners is sufficient in most
integration testing scenarios; however, the TestContextManager
nonetheless logs an INFO message if the @TestExecutionListeners
annotation is not present on an integration test class.

In order to avoid flooding the logs with messages about the absence of
@TestExecutionListeners, this commit reduces the log level for such
messages from INFO to DEBUG.

Issue: SPR-8645

Issue: SPR-9669

* SPR-9669:
  Upgrade to CGLIB 3 and inline into spring-core
  Remove spring-asm and inline ASM 4 into spring-core
  Upgrade JarJar to version 1.3

CGLIB 3 has been released in order to depend on ASM 4, which Spring now
depends on internally (see previous commit).

This commit eliminates spring-beans' optional dependency on cglib-nodep
v2.2 and instead repackages net.sf.cglib => org.springframework.cglib
much in the same way we have historically done with ASM.

This change is beneficial to users in several ways:

 - Eliminates the need to manually add CGLIB to the application
   classpath; especially important for the growing number of
   @Configuration class users. Java-based configuration functionality,
   along with proxy-target-class and method injection features now
   work 'out of the box' in Spring 3.2.

 - Eliminates the possibility of conflicts with other libraries that
   may dependend on differing versions of CGLIB, e.g. Hibernate
   3.3.1.ga and its dependency on CGLIB 2.1.3 would easily cause a
   conflict if the application were depending on CGLIB 3 for
   Spring-related purposes.

 - Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is
   that much less likely to work well in a Java 7 environment due to
   ASM 4's support for transforming classes with invokedynamic
   bytecode instructions.

On CGLIB and ASM:

  CGLIB's own dependency on ASM is also transformed along the way to
  depend on Spring's repackaged org.springframework.asm, primarily to
  eliminate unnecessary duplication of ASM classfiles in spring-core and
  in the process save around 100K in the final spring-core JAR file size.

  It is coincidental that spring-core and CGLIB currently depend on the
  exact same version of ASM (4.0), but it is also unlikely to change any
  time soon. If this change does occur and versions of ASM drift, then
  the size optimization mentioned above will have to be abandoned. This
  would have no compatibility impact, however, so this is a reasonable
  solution now and for the forseeable future.

On a mysterious NoClassDefFoundError:

  During the upgrade to CGLIB 3.0, Spring test cases began failing due to
  NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter
  regarding its use of asm-util's TraceClassVisitor type. previous
  versions of cglib-nodep, particularly 2.2, did not cause this behavior,
  even though cglib-nodep has never actually repackaged and bundled
  asm-util classes. The reason for these NoClassDefFoundErrors occurring
  now is still not fully understood, but appears to be due to subtle JVM
  bytecode preverification rules. The hypothesis is that due to minor
  changes in DebuggingClassWriter such as additional casts, access to
  instance variables declared in the superclass, and indeed a change in
  the superclass hierarchy, preverification may be kicking in on the
  toByteArray method body, at which point the reference to the missing
  TraceClassVisitor type is noticed and the NCDFE is thrown. For this
  reason, a dummy implementation of TraceClassVisitor has been added to
  spring-core in the org.springframework.asm.util package. This class
  simply ensures that Spring's own tests never result in the NCDFE
  described above, and more importantly that Spring's users never
  encounter the same.

Other changes include:

 - rename package-private Cglib2AopProxy => CglibAopProxy
 - eliminate all 'cglibAvailable' checks, warnings and errors
 - eliminate all 'CGLIB2' language in favor of 'CGLIB'
 - eliminate all mention in reference and java docs of needing to add
   cglib(-nodep) to one's application classpath

Issue: SPR-9669

ASM 4.0 is generally compatibile with Java 7 classfiles, particularly
including 'invokedynamic' instructions. This is important when
considering that Spring's component-scanning support is internally
ASM-based and it is increasingly likely that component classes having
invokedynamic instructions may be encountered and read by ASM.
This upgrade, then, is primarily preventive in nature.

Changes include:

 - upgrade from ASM 2.2.3 to ASM 4.0

 - adapt to ASM API changes as necessary throughout spring-core,
   resulting in no impact to the public Spring API.

 - remove dedicated spring-asm module

 - use new :spring-core:asmRepackJar task to repackage
   org.objectweb.asm => org.springframework.asm as per usual and write
   repackaged classes directly into spring-core jar

The choice to eliminate the spring-asm module altogether and instead
inline the repackaged classes directly into spring-core is first to
eliminate an otherwise unnecessary second jar. spring-core has a
non-optional dependency on spring-asm meaning it is always on the
application classpath. This change simplifies that situation by
consoliding two jars into one. The second reason for this choice is in
anticipation of upgrading CGLIB to version 3 and inlining it into
spring-core as well. See subsequent commit for details.

Issue: SPR-9669

JarJar 1.3 now uses ASM 4 in order to be compatible with Java 7
'invokedynamic' instructions. This is not an immediate concern for
the classes that we use JarJar to repackage and transform, but is a
timely upgrade in anticipation of the subsequent commits in which we
upgrade Spring's own dependency on ASM from 2.2.3 to 4.0 and Spring's
dependency on CGLIB from 2.2 to 3.0 (which in turn depends on ASM 4.0).

See https://code.google.com/p/jarjar/wiki/ChangeLog

Issue: SPR-9669

* SPR-9621:
  Avoid NPE when registering a SpEL MethodFilter

Attempting to register a custom MethodFilter with a
StandardEvaluationContext after invoking setMethodResolvers() with a
custom list of MethodResolver instances results in a
NullPointerException. Based on the current documentation in
StandardEvaluationContext it is unclear what the expected behavior
should be, but either the implementation is broken, or the use case is
unsupported. In either case, allowing a NullPointerException to be
thrown is inappropriate.

This commit documents the fact that the SpEL MethodFilter is intended to
be used with the ReflectiveMethodResolver. Furthermore,
StandardEvaluationContext.registerMethodFilter() now throws an
IllegalStateException if the user attempts to set a filter after having
registered a custom set of resolvers.

Issue: SPR-9621

* SPR-9620:
  Support nested double quotes in SpEL expressions

The Spring Expression Language currently supports nested single quotes
within expressions but not nested double quotes.

The SpEL tokenizer has been modified to support nested double quotes in
the same way it supports single quotes. A sequence of two double quotes
will now be replaced by one when evaluated.

Extra error handling has also been added to report when invalid escaping
is encountered, since SpEL does not support escaping with backslash.

Issue: SPR-9620

* SPR-9614:
  Support symbolic boolean operators for OR and AND

SpEL typically supports logical operators for boolean expressions
consistent with standard Java language syntax. However, the operators
for logical AND and logical OR are currently only supported as textual
operators. In other words, SpEL does not support the use of && and || as
logical operators.

The SpEL tokenizer has now been modified to recognize && and || as
symbolic boolean operators. The parser has been modified to allow the
use of either the textual or symbolic operators.

Issue: SPR-9614

Issue: SPR-9660

 - renamed resolveParameterizedReturnType() to
   resolveReturnTypeForGenericMethod()
 - fleshed out Javadoc for resolveReturnType() and
   resolveReturnTypeForGenericMethod() regarding declaration of formal
   type variables
 - improved wording in log statements and naming of local variables
   within resolveReturnTypeForGenericMethod()

Issue: SPR-9493

* SPR-9613:
  Support case-insensitive null literals in SpEL

Prior to this commit null literals in SpEL expressions had to be
specified as "null" (i.e., all lowercase).

With this commit null literals in SpEL expressions are interpreted in a
case-insensitive manner, analogous to the current support for boolean
literals.

Issue: SPR-9613

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

* SPR-9612:
  Modify SpEL Tokenizer to support methods on numbers

When attempting to parse an Integer literal expression such as
42.toString(), SpEL currently throws a SpelParseException with a message
similar to: "EL1041E:(pos 3): After parsing a valid expression, there is
still more data in the expression: 'toString'". The problem here is that
'3.' is currently considered a valid number (including the dot).
However, SpEL succeeds at parsing an equivalent expression for a Double
literal such as 3.14.isInfinite().

To address this issue, the SpEL Tokenizer no longer consumes the
trailing '.' on an integer as part of the integer. So '3.foo()' will now
be parsed as '3' '.' 'foo()' and not '3.' 'foo()' -- which was what
prevented parsing of method invocations on integers. To keep the change
simple, the parser will no longer handle real numbers of the form
'3.e4'. From now on they must include the extra 0 (i.e., '3.0e4').

Issue: SPR-9612

Recently new utility methods were added to JdbcTestUtils, and a
JdbcTemplate was introduced in abstract transactional base classes in
the TestContext framework. This presents an easy opportunity to make
these new utility methods available as convenience methods in the base
test classes.

This commit introduces new countRowsInTableWhere() and dropTables()
convenience methods in the abstract transactional base classes in the
TestContext framework. These new methods internally delegate to methods
of the same names in JdbcTestUtils.

Issue: SPR-9665

Since Spring 2.5, the abstract transactional base classes in the
TestContext framework have defined and delegated to a protected
SimpleJdbcTemplate instance variable; however, SimpleJdbcTemplate has
deprecated since Spring 3.1. Consequently, subclasses of
AbstractTransactionalJUnit4SpringContextTests and
AbstractTransactionalTestNGSpringContextTests that use this instance
variable suffer from seemingly unnecessary deprecation warnings.

This commit addresses this issue by introducing a protected JdbcTemplate
instance variable in abstract transactional base classes to replace the
use of the existing SimpleJdbcTemplate. Furthermore, the existing
simpleJdbcTemplate instance variable has been deprecated, and utility
methods in the affected base classes now delegate to JdbcTestUtils
instead of the now deprecated SimpleJdbcTestUtils.

Issue: SPR-8990

* SPR-9235:
  Deprecate SimpleJdbcTestUtils in favor of JdbcTestUtils

Several static utility methods in SimpleJdbcTestUtils accept an instance
of SimpleJdbcTemplate as an argument; however, SimpleJdbcTemplate has
been deprecated since Spring 3.1 in favor of simply using JdbcTemplate
which now also supports Java 5 language constructs such as var-args.
Consequently, use of such methods from SimpleJdbcTestUtils results in
deprecation warnings without an equivalent API to migrate to.

This commit addresses this issue by migrating all existing methods in
SimpleJdbcTestUtils to JdbcTestUtils. The migrated methods now accept an
instance of JdbcTemplate as an argument, thereby avoiding the
deprecation warnings but maintaining semantic compatibility with the
functionality previous available in SimpleJdbcTestUtils.

In addition, this commit also introduces two new methods:

 - countRowsInTableWhere(): counts the rows in a given table, using
   a provided `WHERE` clause
 - dropTables(): drops the tables with the specified names

Issue: SPR-9235

Introduce MockEnvironment in the spring-test module

For legacy reasons, a MockEnvironment implementation already exists in multiple places within Spring's test suite; however, it is not available to the general public.

This commit promotes MockEnvironment to a first-class citizen in the spring-test module, alongside the existing MockPropertySource.

In addition, the following house cleaning has been performed.

 - deleted MockPropertySource from the spring-expression module
 - deleted MockEnvironment from the "spring" integration testing module
 - updated test copies of MockPropertySource and MockEnvironment
 - documented MockEnvironment and MockPropertySource in the testing
   chapter of the reference manual

Issue: SPR-9492