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

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

Fixed outdated Javadoc regarding support for 'annotated classes' in
the TestContext Framework.

This commit introduces a test suite (Spr8849Tests) that demonstrates
the claims made in SPR-8849.

Specifically, if <jdbc:embedded-database id="xyz" /> is used to create
an embedded HSQL database in an XML configuration file and that
configuration file is imported in different sets of configuration files
that are used to load ApplicationContexts for different integration
tests, the embedded database will be initialized multiple times using
any nested <jdbc:script /> elements. If such a script is used to create
a table, for example, subsequent attempts to initialize the database
named "xyz" will fail since an embedded database named "xyz" already
exists in the JVM.

As a work-around, this test suite uses a SpEL expression to generate a
random string for each embedded database instance:

  id="#{T(java.util.UUID).randomUUID().toString()}"

See the Javadoc in Spr8849Tests for further information.

Issue: SPR-8849

Commit 096693c4 refactored and
deprecated TransactionAspectUtils, moving its #qualifiedBeanOfType
and related methods into BeanFactoryUtils. This created a package cycle
between beans.factory and beans.factory.annotation due to use of the
beans.factory.annotation.Qualifier annotation in these methods.

This commit breaks the package cycle by introducing
beans.factory.annotation.BeanFactoryAnnotationUtils and moving these
@Qualifier-related methods to it. It is intentionally similar in name
and style to the familiar BeanFactoryUtils class for purposes of
discoverability.

There are no backward-compatibilty concerns associated with this change
as the cycle was introduced, caught and now fixed before a release.

Issue: SPR-6847

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

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

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

AbstractTransactionalAnnotatedConfigClassTests is now annotated with
@DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD) so 
that side-effects between tests are avoided.

Re-enabled TransactionalAnnotatedConfigClassWithAtConfigurationTests
and TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests.

Also introduced a log4j FileAppender for tests that writes to
"build/spring-test.log".

Issue: SPR-9051

Issue: SPR-9051

The claim: given an integration test class that is annotated with 
@ContextConfiguration and declares a configuration class that is missing

an @Configuration annotation, if a transactional test method (i.e., one 
annotated with @Transactional) changes the state of the database then
the 
changes will not be rolled back as would be expected with the default 
rollback semantics of the Spring TestContext Framework (TCF).

TransactionalAnnotatedConfigClassWithAtConfigurationTests is a concrete 
implementation of AbstractTransactionalAnnotatedConfigClassTests that
uses 
a true @Configuration class and thereby demonstrates the expected
behavior 
of such transactional tests with automatic rollback.

TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests is a 
concrete implementation of
AbstractTransactionalAnnotatedConfigClassTests 
that does NOT use a true @Configuration class but rather a 'lite mode'
configuration class (see the Javadoc for @Bean for details).

Using such a 'lite mode' configuration class results in the following:

 - Its @Bean methods act as factory methods instead of singleton beans.
 - The dataSource() method is invoked multiple times instead of once.
 - The test instance and the TCF operate on different data sources.
 - The transaction managed (and rolled back) by the TCF is not the 
   transaction that the application code or test instance uses.

Ultimately, the use of a 'lite mode' configuration class gives the false
appearance that there is a bug in the TCF (in that the transaction is
not 
rolled back); however, the transaction managed by the TCF is in fact 
rolled back.

In conclusion, these tests demonstrate both the intended behavior of the

TCF and the fact that using 'lite mode' configuration classes can lead
to 
confusing results (both in tests and production code).

Issue: SPR-9051

It was claimed that when a {@code @ContextConfiguration} test class
references a config class missing an {@code @Configuration} annotation,
@Bean dependencies are wired successfully but the bean lifecycle is not
applied (no init methods are invoked, for example).

AnnotatedConfigClassesWithoutAtConfigurationTests refutes this claim by
demonstrating that @Bean methods in non-@Configuration classes are
properly handled as "annotated factory bean methods" and that lifecycle
callbacks in fact apply to such factory beans.

Issue: SPR-9051

Two tests in MockServletContextTests were disabled with @Ignore with the
comment "fails to work under ant after move from .testsuite -> .test";
however, this no longer appears to apply with the Gradle build. Thus
these tests have been re-enabled.

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

Before this change javadoc in two classes had non-UTF-8 encoded
characters. This caused building Spring API to fail in Java 1.7.

Commit fixes this by replacing wrongly encoded characters with their
UTF-8 equivalents.

Issue: SPR-9097

Each of these tests began failing during the Gradle build porting
process. None seem severe, many are likely due to classpath issues.

In the case of TestNG support, this needs to be added to the Gradle
build in order to execute these tests. See SPR-8116.txt

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