Spring Framework 4.0 introduced first-class support for a Groovy-based
DSL for defining the beans for an ApplicationContext. However, prior to
this commit, the Spring TestContext Framework (TCF) did not provide any
out-of-the-box support for using Groovy scripts as path-based resource
locations when loading an application context for tests.

This commit addresses this issue by introducing first-class support for
using Groovy scripts to load the ApplicationContext for integration
tests managed by the TCF. Specifically, the following changes have been
made in the TCF to support Groovy scripts.

 - Introduced getResourceSuffixes() in AbstractContextLoader in order
   to support multiple resource suffixes in the default detection
   process. This feature is used by the new Groovy/Xml context loaders.

 - Introduced GenericGroovyXmlContextLoader and
   GenericGroovyXmlWebContextLoader which support both Groovy scripts
   and XML config files for loading bean definitions. Furthermore,
   these loaders support "-context.xml" and "Context.groovy" as
   resource suffixes when detecting defaults. Note that a default XML
   config file will be detected before a default Groovy script.

 - DelegatingSmartContextLoader and WebDelegatingSmartContextLoader now
   use reflection to choose between using GenericGroovyXmlContextLoader
   and GenericGroovyXmlWebContextLoader vs. GenericXmlContextLoader and
   GenericXmlWebContextLoader as their XML loaders, depending on
   whether Groovy is present in the classpath.

 - Groovy scripts can be configured via the 'locations' or 'value'
   attributes of @ContextConfiguration and can be mixed seamlessly with
   XML config files.

Issue: SPR-11233

Overhauled class-level Javadoc for TransactionalTestExecutionListener:

 - Reorganized content.
 - Added headings to paragraphs.
 - Documented TestTransaction support.

Issue: SPR-11941

Prior to this commit, the support for SQL script execution via @Sql
provided an algorithm for looking up a required
PlatformTransactionManager to use to drive transactions. However, a
transaction manager is not actually required for all testing scenarios.

This commit improves the transaction management support for @Sql so
that SQL scripts can be executed without a transaction if a transaction
manger is not present in the ApplicationContext. The updated algorithm
now supports the following use cases.

 - If a transaction manager and data source are both present (i.e.,
   explicitly specified via the transactionManager and dataSource
   attributes of @SqlConfig or implicitly discovered in the
   ApplicationContext based on conventions), both will be used.

 - If a transaction manager is not explicitly specified and not
   implicitly discovered based on conventions, SQL scripts will be
   executed without a transaction but requiring the presence of a data
   source. If a data source is not present, an exception will be thrown.

 - If a data source is not explicitly specified and not implicitly
   discovered based on conventions, an attempt will be made to retrieve
   it by using reflection to invoke a public method named
   getDataSource() on the transaction manager. If this attempt fails,
   an exception will be thrown.

 - If a data source can be retrieved from the resolved transaction
   manager using reflection, an exception will be thrown if the
   resolved data source is not the data source associated with the
   resolved transaction manager. This helps to avoid possibly
   unintended configuration errors.

 - If @SqlConfig.transactionMode is set to ISOLATED, an exception will
   be thrown if a transaction manager is not present.

Issue: SPR-11911

Prior to this commit, @Sql provided attributes for configuring the
syntax of the referenced SQL scripts as well as exception handling and
transaction behavior; however, such configuration could not be reused
across @Sql declarations thus requiring developers to copy-and-paste
common configuration and resulting in unnecessary code duplication.

This commit addresses this issue by introducing a new @SqlConfig
annotation that can be used to declare common, global configuration for
SQL scripts that can be reused within a test class hierarchy.

 - Introduced top-level @SqlConfig annotation and extracted
   common configuration attributes from @Sql.

 - @SqlConfig can be used at the class level for common, global config
   or via the new 'config' attribute of @Sql for local config.

 - Introduced MergedSqlConfig as a holder for the merged values from
   local and global @SqlConfig instances. MergedSqlConfig also contains
   the logic for overriding global configuration with local
   configuration.

 - Refactored all attributes of @SqlConfig to be either of type String
   or custom enums in order to support overriding. Empty Strings or
   DEFAULT enum values imply the use of a default or inherited value.

Issue: SPR-11896

Historically, Spring's JUnit 3.8 TestCase class hierarchy supported
programmatic transaction management of "test-managed transactions" via
the protected endTransaction() and startNewTransaction() methods in
AbstractTransactionalSpringContextTests.

The Spring TestContext Framework (TCF) was introduced in Spring 2.5 to
supersede the legacy JUnit 3.8 support classes; however, prior to this
commit the TCF has not provided support for programmatically starting
or stopping the test-managed transaction.

This commit introduces a TestTransaction class in the TCF that provides
static utility methods for programmatically interacting with
test-managed transactions. Specifically, the following features are
supported by TestTransaction and its collaborators.

 - End the current test-managed transaction.

 - Start a new test-managed transaction, using the default rollback
   semantics configured via @TransactionConfiguration and @Rollback.

 - Flag the current test-managed transaction to be committed.

 - Flag the current test-managed transaction to be rolled back.

Implementation Details:

 - TransactionContext is now a top-level, package private class.

 - The existing test transaction management logic has been extracted
   from TransactionalTestExecutionListener into TransactionContext.

 - The current TransactionContext is stored in a
   NamedInheritableThreadLocal that is managed by
   TransactionContextHolder.

 - TestTransaction defines the end-user API, interacting with the
   TransactionContextHolder behind the scenes.

 - TransactionalTestExecutionListener now delegates to
   TransactionContext completely for starting and ending transactions.

Issue: SPR-5079

Prior to this commit, the Spring TestContext Framework (TCF) was
compatible with JUnit 4.5 or higher.

This commit effectively raises the minimum version of JUnit that is
officially supported by the TCF to JUnit 4.9, thereby aligning with
similar upgrades made in the Spring Framework 4.0 release (i.e.,
upgrading minimum requirements on third-party libraries to versions
released mid 2010 or later).

Issue: SPR-11908

Prior to this commit, SQL script annotations and related classes in the
TestContext framework (TCF) were named DatabaseInitializer*. However,
these annotations are not used only for initialization and are
therefore misleading when used for cleaning up the database.

This commit refines the names of annotations and related classes for
configuring SQL scripts to be executed for integration tests in the TCF
as follows:

- @DatabaseInitializer -> @Sql
- @DatabaseInitializers -> @SqlGroup
- DatabaseInitializerTestExecutionListener -> SqlScriptsTestExecutionListener

A special thanks goes out to the following attendees of the Zurich
Hackergarten meeting last night for their collective brainstorming:
@aalmiray, @atsticks, @ollin, @simkuenzi, @tangresh, @vyazelenko.

Issue: SPR-7655

Prior to this commit, it was possible to execute SQL scripts
programmatically via ResourceDatabasePopulator, JdbcTestUtils, and
ScriptUtils. Furthermore, it was also possible to execute SQL scripts
declaratively via the <jdbc> XML namespace. However, it was not
possible to execute SQL scripts declaratively on a per test class or
per test method basis.

This commit makes it possible to declaratively configure SQL scripts
for execution in integration tests via annotations that can be declared
at the class or method level. Details follow.

 - Introduced a repeatable @DatabaseInitializer annotation that can be
   used to configure SQL scripts at the class or method level with
   method-level overrides. @DatabaseInitializers serves as a container
   for @DatabaseInitializer.

 - Introduced a new DatabaseInitializerTestExecutionListener that is
   responsible for parsing @DatabaseInitializer and
   @DatabaseInitializers and executing SQL scripts.

 - DatabaseInitializerTestExecutionListener is registered by default in
   abstract base test classes as well as in TestContextBootstrapper
   implementations.

 - @DatabaseInitializer and @DatabaseInitializers may be used as
   meta-annotations; however, attribute overrides are not currently
   supported for repeatable annotations used as meta-annotations. This
   is a known limitation of Spring's AnnotationUtils.

 - The semantics for locating SQL script resources is consistent with
   @ContextConfiguration's semantics for locating XML configuration
   files. In addition, a default SQL script can be detected based
   either on the name of the annotated class or on the name of the
   annotated test method.

 - @DatabaseInitializer allows for specifying which DataSource and
   PlatformTransactionManager to use from the test's
   ApplicationContext, including default conventions consistent with
   TransactionalTestExecutionListener and @TransactionConfiguration.

 - @DatabaseInitializer supports all of the script configuration options
   currently supported by ResourceDatabasePopulator.

 - @DatabaseInitializer and DatabaseInitializerTestExecutionListener
   support execution phases for scripts that dictate when SQL scripts
   are executed (i.e., before or after a test method).

 - SQL scripts can be executed within the current test's transaction if
   present, outside of the current test's transaction if present, or
   always in a new transaction, depending on the value of the boolean
   requireNewTransaction flag in @DatabaseInitializer.

 - DatabaseInitializerTestExecutionListener delegates to
   ResourceDatabasePopulator#execute to actually execute the scripts.

Issue: SPR-7655

Consistently log Class.getName() instead of Class.toString(), avoiding double class term in log message

Issue: SPR-11804

Consistently log Class.getName() instead of Class.toString(), avoiding double class term in log message

Issue: SPR-11804

Issue: SPR-11804

Issue: SPR-11721
(cherry picked from commit 59cef3ce)

Work done in conjunction with SPR-5243 and SPR-4588 introduced physical
package cycles in the spring-test module. The work performed in
conjunction with SPR-9924 uses reflection to resolve these physical
package cycles; however, prior to this commit the logical package
cycles still remain.

Furthermore, over time it has become apparent that the Spring
TestContext Framework (TCF) could better serve application developers
and especially third-party framework developers by providing a more
flexible mechanism for "bootstrapping" the TCF. For example, prior to
this commit, default TestExecutionListeners could only be registered by
subclassing TestContextManager (and SpringJUnit4ClassRunner if using
JUnit). Similarly, the default ContextLoader could only be set by
subclassing SpringJUnit4ClassRunner for JUnit and by copying and
modifying AbstractTestNGSpringContextTests for TestNG.

This commit addresses the aforementioned issues by introducing a
bootstrap strategy in the TestContext framework that is responsible for
determining default TestExecutionListeners and the default
ContextLoader in an extensible fashion. The new TestContextBootstrapper
SPI also provides a mechanism for supporting various types of
MergedContextConfiguration depending on the feature set of the context
loaders supported by the strategy.

The following provides an overview of the most significant changes in
this commit.

 - Introduced TestContextBootstrapper strategy SPI, BootstrapContext,
   and @BootstrapWith.

 - Introduced AbstractTestContextBootstrapper,
   DefaultTestContextBootstrapper, and WebTestContextBootstrapper
   implementations of the TestContextBootstrapper SPI and extracted
   related reflection code from ContextLoaderUtils & TestContextManager.

 - Introduced BootstrapUtils for retrieving the TestContextBootstrapper
   from @BootstrapWith, falling back to a default if @BootstrapWith is
   not present.

 - @WebAppConfiguration is now annotated with
   @BootstrapWith(WebTestContextBootstrapper.class).

 - CacheAwareContextLoaderDelegate is now an interface with a new
   DefaultCacheAwareContextLoaderDelegate implementation class.

 - Introduced closeContext(MergedContextConfiguration, HierarchyMode) in
   CacheAwareContextLoaderDelegate.

 - DefaultTestContext now uses CacheAwareContextLoaderDelegate instead
   of interacting directly with the ContextCache.

 - DefaultTestContext now delegates to a TestContextBootstrapper for
   building the MergedContextConfiguration.

 - TestContextManager now delegates to TestContextBootstrapper for
   retrieving TestExecutionListeners.

 - Deleted TestContextManager(Class, String) constructor and
   SpringJUnit4ClassRunner.getDefaultContextLoaderClassName(Class)
   method since default ContextLoader support is now implemented by
   TestContextBootstrappers.

 - Extracted ActiveProfilesUtils from ContextLoaderUtils.

 - Extracted ApplicationContextInitializerUtils from ContextLoaderUtils.

 - MetaAnnotationUtils is now a public utility class in the test.util
   package.

 - Removed restriction in @ActiveProfiles that a custom resolver cannot
   be used with the 'value' or 'profiles' attributes.

 - Introduced DefaultActiveProfilesResolver.

Issue: SPR-9955

Prior to this commit, the Spring TestContext Framework did not support
the declaration of both 'locations' and 'classes' within
@ContextConfiguration at the same time.

This commit addresses this in the following manner:

 - ContextConfigurationAttributes no longer throws an
   IllegalArgumentException if both 'locations' and 'classes' are
   supplied to its constructor.

 - Concrete SmartContextLoader implementations now validate the
   supplied MergedContextConfiguration before attempting to load the
   ApplicationContext. See validateMergedContextConfiguration().

 - Introduced tests for hybrid context loaders like the one used in
   Spring Boot. See HybridContextLoaderTests.

 - Updated the Testing chapter of the reference manual so that it no
   longer states that locations and classes cannot be used
   simultaneously, mentioning Spring Boot as well.

 - The Javadoc for @ContextConfiguration has been updated accordingly.

 - Added hasLocations(), hasClasses(), and hasResources() convenience
   methods to MergedContextConfiguration.

Issue: SPR-11634

To simplify common use cases, this commit introduces a new
execute(DataSource) method in ResourceDatabasePopulator that complements
the existing populate(Connection) method.

Issue: SPR-11629

Prior to this commit, if multiple test methods were executed in a
subclass of AbstractTestNGSpringContextTests annotated with
@WebAppConfiguration, then injected Servlet API mocks would only
reference the mocks created for the first test method. Subsequent test
methods could therefore never reference the current mocks, and there
was a discrepancy between the state of the injected mocks and the mock
set in the RequestContextHolder.

This commit addresses this issue by ensuring that dependencies
(including updated mocks) are injected into the test instance before
the next test method if the ServletTestExecutionListener resets the
request attributes in RequestContextHolder.

Issue: SPR-11626