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

Currently the Spring TestContext Framework looks up a
PlatformTransactionManager bean named "transactionManager". The exact
name of the bean can be overridden via @TransactionConfiguration or
@Transactional; however, the bean will always be looked up 'by name'.

The TransactionManagementConfigurer interface that was introduced in
Spring 3.1 provides a programmatic approach to specifying the
PlatformTransactionManager bean to be used for annotation-driven
transaction management, and that bean is not required to be named
"transactionManager". However, as of Spring 3.1.2, using the
TransactionManagementConfigurer on a @Configuration class has no effect
on how the TestContext framework looks up the transaction manager.
Consequently, if an explicit name or qualifier has not been specified,
the bean must be named "transactionManager" in order for a transactional
integration test to work.

This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it looks up and delegates to
a single TransactionManagementConfigurer as part of the algorithm for
determining the transaction manager.

Issue: SPR-9604

TransactionalTestExecutionListener currently requires that the
PlatformTransactionManager bean be named "transactionManager" by
default. Otherwise, the bean name can only be overridden via the
transactionManager attribute of @TransactionConfiguration or the value
attribute of @Transactional.

However, if there is only a single PlatformTransactionManager in the
test's ApplicationContext, then the requirement to specify the exact
name of that bean (or to name it exactly "transactionManager") is often
superfluous.

This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it is comparable to the
algorithm for determining the transaction manager used in
TransactionAspectSupport for "production" code. Specifically, the TTEL
now uses the following algorithm to retrieve the transaction manager.

 - look up by type and qualifier from @Transactional
 - else, look up by type and explicit name from
   @TransactionConfiguration
 - else, look up single bean by type
 - else, look up by type and default name from @TransactionConfiguration

Issue: SPR-9645

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

Usually this request attribute is set for all sub-classes of
AbstractUrlHandlerMapping and therefore whenever
AnnotationMethodHandlerAdapter is used. However, having a
default value to fall back on in AnnotationMethodHandlerAdapter
is still appropriate in general and also considering the Javadoc
of HandlerMapping.INTROSPECT_TYPE_LEVEL_MAPPING.

Issue: SPR-9629

Issue: SPR-9601

The new FactoryBean facilitates the creation of a
ContentNegotiationManager in XML configuration.

Issue: SPR-8420

The MVC Java config and the MVC namespace now support options to
configure content negotiation. By default both support checking path
extensions first and the "Accept" header second. For path extensions
.json, .xml, .atom, and .rss are recognized out of the box if the
Jackson, JAXB2, or Rome libraries are available. The ServletContext
and the Java Activation Framework may be used as fallback options
for path extension lookups.

Issue: SPR-8420

Add the ability provide exclude patterns for mapped interceptors in the
MVC namespace and in the MVC Java config.

Issue: SPR-6570

Issue: SPR-9611

After this change each call stack level pushes and pops an async
Callable to ensure the AsyncExecutionChain is in sync with the
call stack. Before this change, a controller returning a "forward:"
prefixed string caused the AsyncExecutionChain to contain a
extra Callables that did not match the actual call stack.

Issue: SPR-9611

Issue: SPR-9500

Issue: SPR-9579

* SPR-9594:
  Fix minor issue in MockHttpServletRequest

Previously MockHttpServletRequest#sendRedirect did not set the HTTP status
or the Location header. This does not conform to the HttpServletRequest
interface.

MockHttpServletRequest will now:

  - Set the HTTP status to 302 on sendRedirect
  - Set the Location header on sendRedirect
  - Ensure the Location header and getRedirectedUrl are kept in synch

Issue: SPR-9594

Update section on exception handling in Spring MVC chapter to include
more guidance on exception handling when implementing a REST API.

Issue: SPR-9290

Previously DefaultHandlerExceptionResolver did not handle BindException
but after this change it does. A BindException is raised when an
@ModelAttribute annotated argument is not followed by a BindingResult
argument. Hence this is unlikely to affect browser rendering.
For programmatic clients however this change ensures an unhandled
BindException is at least turned into a 400 error.

Issue: SPR-9310

The Atom/RSS message converters are now registered ahead of the
Jackson and the JAXB2 message converters by default. Since the Atom
and RSS converters convert to and from very specific object types
Feed and Channel respectively, that shouldn't introduce any regressions
and will work more intuitively when the requested media type is "*/*".

Issue: SPR-9054

* SPR-9576:
  Include **/*.aj files in *-sources.jar files

Previously only **/*.java sources files were included in the sources
jars. This is not ideal for the spring-aspects jar nor does it match
prior versions of the sources jars.

Now **/*.aj files are included in addition to the **/*.java files.

Issue: SPR-9576

Issue: SPR-9112

Before this change @ExceptionHandler methods could be located in and
apply locally within a controller. The change makes it possible to have
such methods applicable globally regardless of the controller that
raised the exception.

The easiest way to do that is to add them to a class annotated with
`@ExceptionResolver`, a new annotation that is also an `@Component`
annotation (and therefore works with component scanning). It is also
possible to register classes containing `@ExceptionHandler` methods
directly with the ExceptionHandlerExceptionResolver.

When multiple `@ExceptionResolver` classes are detected, or registered
directly, the order in which they're used depends on the the `@order`
annotation (if present) or on the value of the order field (if the
Ordered interface is implemented).

Issue: SPR-9112

Issue: SPR-9480

 Issue: SPR-9487

Prior to this change, PropertySourcesPropertyResolver (and therefore
all AbstractEnvironment) implementations failed to resolve nested
placeholders as in the following example:

    p1=v1
    p2=v2
    p3=${v1}:{$v2}

Calls to PropertySource#getProperty for keys 'p1' and 'v1' would
successfully return their respective values, but for 'p3' the return
value would be the unresolved placeholders. This behavior is
inconsistent with that of PropertyPlaceholderConfigurer.

PropertySourcesPropertyResolver #getProperty variants now resolve any
nested placeholders recursively, throwing IllegalArgumentException for
any unresolvable placeholders (as is the default behavior for
PropertyPlaceholderConfigurer). See SPR-9569 for an enhancement that
will intoduce an 'ignoreUnresolvablePlaceholders' switch to make this
behavior configurable.

This commit also improves error output in
PropertyPlaceholderHelper#parseStringValue by including the original
string in which an unresolvable placeholder was found.

Issue: SPR-9473, SPR-9569

Before this change HandlerMethod used ClassUtils.getUserClass(Class<?>)
to get the real user class, and not one generated by CGlib. However it
failed to that under all circumstances. This change fixes that.

Issue: SPR-9490

Before this change the StringHttpMessageConverter used a fixed charset
"ISO-8859-1" if the requested content type did not specify one. This
change adds a defaultCharset field and a constructor to configure it in
StringHttpMessageConverter.

Issue: SPR-9487