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
This commit is a general update of the Cache Abstraction chapter.
Existing sections have been updated with recent improvements made in
that area, in particular:
* Guava and JSR-107 caches support
* New @CacheConfig annotation allowing to share some key customizations
at class-level
* CacheResolver interface used to resolve the cache(s) to use at
runtime
* Update section on @CachePut
This commit also describes the support of standard JCache annotations,
i.e. JSR-107.
Issues: SPR-11490, SPR-11316, SPR-10629, SPR-9616, SPR-8696
This commit fixes the handling of cached exceptions in the JSR-107
advisor. Such exceptions are now properly propagated instead of being
wrapped in a RuntimeException.
Issue: SPR-9616
Prior to this commit, AnnotatedJCacheableService contained an annotated
method demonstrating a failure scenario. This could break depending on
the order of the methods array as AopUtils creates the proxy if the
pointcut matches by checking each method.
On the CI server, the first method was this invalid use case so
checking if the proxy has to be created lead to an unexpected
exception. This scenario has been moved to its own private class now.
Prior to this commit, the CacheResolver was not used by Spring's
caching abstraction. This commit provides the necessary configuration
options to tune how a cache is resolved for a given operation.
CacheResolver can be customized globally, at the operation level or at
the class level. This breaks the CachingConfigurer class and a support
implementation is provided that implements all methods so that the
default is taken if it's not overridden. The JSR-107 support has been
updated as well, with a similar support class.
In particular, the static and runtime information of a cache
operation were mixed which prevents any forms of caching. As the
CacheResolver and the KeyGenerator can be customized, every operation
call lead to a lookup in the context for the bean.
This commit adds CacheOperationMetadata, a static holder of all
the non-runtime metadata about a cache operation. This is used
as an input source for the existing CacheOperationContext.
Caching the operation metadata in an AspectJ aspect can have side
effects as the aspect is static instance for the current ClassLoader.
The metadata cache needs to be cleared when the context shutdowns.
This is essentially a test issue only as in practice each application
runs in its class loader. Tests are now closing the context properly
to honor the DisposableBean callback.
Issue: SPR-11490
This commit adds support for the JSR-107 cache annotations alongside
the Spring's cache annotations, that is @CacheResult, @CachePut,
@CacheRemove and @CacheRemoveAll as well as related annotations
@CacheDefaults, @CacheKey and @CacheValue.
Spring's caching configuration infrastructure detects the presence of
the JSR-107 API and Spring's JCache implementation. Both
@EnableCaching and the cache namespace are able to configure the
required JCache infrastructure when necessary. Both proxy mode
and AspectJ mode are supported.
As JSR-107 permits the customization of the CacheResolver to use for
both regular and exception caches, JCacheConfigurer has been
introduced as an extension of CachingConfigurer and permits to define
those.
If an exception is cached and should be rethrown, it is cloned and
the call stack is rewritten so that it matches the calling thread each
time. If the exception cannot be cloned, the original exception is
returned.
Internally, the interceptors uses Spring's caching abstraction by default
with an adapter layer when a JSR-107 component needs to be called.
This is the case for CacheResolver and CacheKeyGenerator.
The implementation uses Spring's CacheManager abstraction behind the
scene. The standard annotations can therefore be used against any
CacheManager implementation.
Issue: SPR-9616
This commit introduces an explicit integration test to verify that a
PropertySource can be set via a custom ApplicationContextInitializer in
the Spring TestContext Framework.
Issue: SPR-11666
Prior to this commit, there were numerous places in the reference
manual, where we would see output similar to the following:
BeanDefinition`s with the `ApplicationContext
This commit addresses this issue by using unconstrained quotes
(e.g., ++XYZ++s) instead of backticks (e.g., `XYZ`s) when the formatted
text is immediately followed by an "s".
This commit also corrects a few typos and corrects natural English
pluralization of Java code elements in the reference manual where
appropriate -- for example, "@Controllers" becomes "@Controller classes,
etc.
Issue: SPR-11650
The UserDestinationMessageHandler adds a header providing a hint for
what the original destination a user may have used when subscribing.
That is then used when writing messages back to WebSocket clients to
ensure they dont see the internally used, transformed user destination.
This change moves the header name constatn to make it more broadly
applicable. For example SPR-11645.
Prior to this commit, @SubscribeMapping mapped methods (backed with
@SendTo* annotations, or not) would send MESSAGEs with the wrong
destination. Instead of using the original SUBSCRIBE destination, it
would use the lookup path computed from the configured prefixes in the
application.
This commit fixes this issue - now @SubscribeMapping MESSAGEs use the
original SUBSCRIBE destination.
Issue: SPR-11648
This commit adds a putIfAbsent method to the Cache interface. This
method offers an atomic put if the key is not already associated in
the cache.
Issue: SPR-11400
This commit updates a number of dependencies upon Java EE specs to
use the preferred artifacts. Part of this change has been to move
to new API artifacts for both JSTL and JavaMail. In both cases these
new API jars are genuine API jars, i.e. they no longer contain an
implementation. Where needed, implementation dependencies have been
added.
Prior to this commit, an exception thrown by an @Async void method
was not further processed as there is no way to transmit that
exception to the caller.
The AsyncUncaughtExceptionHandler is a new strategy interface that
can be implemented to handle unexpected exception thrown during the
invocation of such asynchronous method.
The handler can be specified using either the XML namespace or by
implementing the AsyncConfigurer interface with the EnableAsync
annotation.
Issue: SPR-8995
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
Update some native WebSocket session getters to return basic
information after it is closed. It is required for example in
SubProtocolWebSocketHandler#afterConnectionEstablished() or
StompSubProtocolHandler#afterSessionStarted().
Issue: SPR-11621
Prior to this commit, a cache that is added on-the-fly is not properly
decorated by the provided CacheManager implementation that supports
it (EhCache and JCache).
This commits adds an extra getMissingCache method to
the AbstractCacheManager that can be extended to provide a cache that
may exist in the native cache manager but is not yet known by the
spring abstraction.
Issue: SPR-11518
This commit rationalizes the use of @Order so that the standard
@Priority annotation can be used instead. The handling of both
annotations are now defined in OrderUtils.
This also updates the link to the JavaEE API so that we refer to
JavaEE7 instead of JavaEE6.
Issue: SPR-11639
This commit adds support for @Priority to filter multiple candidates
for autowiring. When multiple candidates are available for a given
bean, the bean annotated with @Primary is used. If none exists, the
one with the higher value for the @Priority annotation is used. If
two beans have the same priority a NoUniqueBeanDefinitionException
is thrown, just as if two beans are annotated with @Primary.
The underlying code for #getBean and #resolveDependency has been
merged as this feature is available for both dependency injection
and bean lookup by type.
Issue: SPR-10548
