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
Prior to this commit the Spring TestContext Framework supported creating
only flat, non-hierarchical contexts. There was no easy way to create
contexts with parent-child relationships.
This commit addresses this issue by introducing a new @ContextHierarchy
annotation that can be used in conjunction with @ContextConfiguration
for declaring hierarchies of application contexts, either within a
single test class or within a test class hierarchy. In addition,
@DirtiesContext now supports a new 'hierarchyMode' attribute for
controlling context cache clearing for context hierarchies.
- Introduced a new @ContextHierarchy annotation.
- Introduced 'name' attribute in @ContextConfiguration.
- Introduced 'name' property in ContextConfigurationAttributes.
- TestContext is now aware of @ContextHierarchy in addition to
@ContextConfiguration.
- Introduced findAnnotationDeclaringClassForTypes() in AnnotationUtils.
- Introduced resolveContextHierarchyAttributes() in ContextLoaderUtils.
- Introduced buildContextHierarchyMap() in ContextLoaderUtils.
- @ContextConfiguration and @ContextHierarchy may not be used as
top-level, class-level annotations simultaneously.
- Introduced reference to the parent configuration in
MergedContextConfiguration and WebMergedContextConfiguration.
- Introduced overloaded buildMergedContextConfiguration() methods in
ContextLoaderUtils in order to handle context hierarchies separately
from conventional, non-hierarchical contexts.
- Introduced hashCode() and equals() in ContextConfigurationAttributes.
- ContextLoaderUtils ensures uniqueness of @ContextConfiguration
elements within a single @ContextHierarchy declaration.
- Introduced CacheAwareContextLoaderDelegate that can be used for
loading contexts with transparent support for interacting with the
context cache -- for example, for retrieving the parent application
context in a context hierarchy.
- TestContext now delegates to CacheAwareContextLoaderDelegate for
loading contexts.
- Introduced getParentApplicationContext() in MergedContextConfiguration
- The loadContext(MergedContextConfiguration) methods in
AbstractGenericContextLoader and AbstractGenericWebContextLoader now
set the parent context as appropriate.
- Introduced 'hierarchyMode' attribute in @DirtiesContext with a
corresponding HierarchyMode enum that defines EXHAUSTIVE and
CURRENT_LEVEL cache removal modes.
- ContextCache now internally tracks the relationships between contexts
that make up a context hierarchy. Furthermore, when a context is
removed, if it is part of a context hierarchy all corresponding
contexts will be removed from the cache according to the supplied
HierarchyMode.
- AbstractGenericWebContextLoader will set a loaded context as the
ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE in the MockServletContext when
context hierarchies are used if the context has no parent or if the
context has a parent that is not a WAC.
- Where appropriate, updated Javadoc to refer to the
ServletTestExecutionListener, which was introduced in 3.2.0.
- Updated Javadoc to avoid and/or suppress warnings in spring-test.
- Suppressed remaining warnings in code in spring-test.
Issue: SPR-5613, SPR-9863
This commit introduces RequestAndSessionScopedBeansWacTests which
verifies support for request and session scoped beans in the Spring
TestContext Framework (TCF).
This support was actually introduced as an intentional side effect of
the work performed for SPR-5243 through the addition of the new
WebTestExecutionListener.
Issue: SPR-4588
Prior to this commit, the Spring TestContext Framework only supported
loading an ApplicationContext in integration tests from either XML or
Java Properties files (since Spring 2.5), and Spring 3.1 introduced
support for loading an ApplicationContext in integration tests from
annotated classes (e.g., @Configuration classes). All of the
ContextLoader implementations used to provide this support load a
GenericApplicationContext. However, a GenericApplicationContext is not
suitable for testing a web application since a web application relies on
an implementation of WebApplicationContext (WAC).
This commit makes it possible to integration test Spring-powered web
applications by adding the following functionality to the Spring
TestContext Framework.
- Introduced AbstractGenericWebContextLoader and two concrete
subclasses:
- XmlWebContextLoader
- AnnotationConfigWebContextLoader
- Pulled up prepareContext(context, mergedConfig) from
AbstractGenericContextLoader into AbstractContextLoader to allow it
to be shared across web and non-web context loaders.
- Introduced AnnotationConfigContextLoaderUtils and refactored
AnnotationConfigContextLoader accordingly. These utils are also used
by AnnotationConfigWebContextLoader.
- Introduced a new @WebAppConfiguration annotation to denote that the
ApplicationContext loaded for a test should be a WAC and to configure
the base resource path for the root directory of a web application.
- Introduced WebMergedContextConfiguration which extends
MergedContextConfiguration with support for a baseResourcePath for
the root directory of a web application.
- ContextLoaderUtils.buildMergedContextConfiguration() now builds a
WebMergedContextConfiguration instead of a standard
MergedContextConfiguration if @WebAppConfiguration is present on the
test class.
- Introduced a configureWebResources() method in
AbstractGenericWebContextLoader that is responsible for creating a
MockServletContext with a proper ResourceLoader for the
resourceBasePath configured in the WebMergedContextConfiguration. The
resulting mock ServletContext is set in the WAC, and the WAC is
stored as the Root WAC in the ServletContext.
- Introduced a WebTestExecutionListener that sets up default thread
local state via RequestContextHolder before each test method by using
the MockServletContext already present in the WAC and by creating a
MockHttpServletRequest, MockHttpServletResponse, and
ServletWebRequest that is set in the RequestContextHolder. WTEL also
ensures that the MockHttpServletResponse and ServletWebRequest can be
injected into the test instance (e.g., via @Autowired) and cleans up
thread locals after each test method.
- WebTestExecutionListener is configured as a default
TestExecutionListener before DependencyInjectionTestExecutionListener
- Extracted AbstractDelegatingSmartContextLoader from
DelegatingSmartContextLoader and introduced a new
WebDelegatingSmartContextLoader.
- ContextLoaderUtils now selects the default delegating ContextLoader
class name based on the presence of @WebAppConfiguration on the test
class.
- Tests in the spring-test-mvc module no longer use a custom
ContextLoader to load a WebApplicationContext. Instead, they now
rely on new core functionality provided in this commit.
Issue: SPR-5243
Starting with Spring 3.1 applications can specify
contextInitializerClasses via context-param and init-param in web.xml;
however, there is currently no way to have such initializers invoked in
integration testing scenarios without writing a custom
SmartContextLoader. For comprehensive integration testing it should
therefore be possible to re-use ApplicationContextInitializers in the
Spring TestContext Framework as well.
This commit makes this possible at the @ContextConfiguration level by
allowing an array of ACI types to be specified, and the out-of-the-box
SmartContextLoader implementations invoke the declared initializers at
the appropriate time.
- Added initializers and inheritInitializers attributes to
@ContextConfiguration.
- Introduced support for ApplicationContextInitializers in
ContextConfigurationAttributes, MergedContextConfiguration, and
ContextLoaderUtils.
- MergedContextConfiguration stores context initializer classes as a
Set and incorporates them into the implementations of hashCode() and
equals() for proper context caching.
- ApplicationContextInitializers are invoked in the new
prepareContext(GenericApplicationContext, MergedContextConfiguration)
method in AbstractGenericContextLoader, and ordering declared via the
Ordered interface and @Order annotation is honored.
- Updated DelegatingSmartContextLoader to support initializers.
Specifically, a test class may optionally declare neither XML
configuration files nor annotated classes and instead declare only
application context initializers. In such cases, an attempt will
still be made to detect defaults, but their absence will not result
an an exception.
- Documented support for application context initializers in Javadoc
and in the testing chapter of the reference manual.
Issue: SPR-9011
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
Sam Brannen
Chris Beams