Prior to this commit, setting the parameters used to build the caches
was fragile in static mode as the caches were created right when the
setCacheNames setter was called.
This commit provides a better handling of such arguments and also
provide a way to restore the dynamic mode if necessary.
Issue: SPR-12120
This commit adds an extra test implementation that runs the cache
abstraction tests using a JSR-107 cache manager. This further covers
JCacheCacheManager.
The actual JSR-107 implementation is ehcache-jcache that requires at
least ehcache 2.8.3. Since the ehcache-core artifact is no longer a
public artifact, this commit switches to the full ehcache library,
that is net.sf.ehcache:ehcache
This commit adds a invokeOperation protected method in case one
needs a hook point in the way the underlying cache method is invoked,
and how exceptions that might be thrown by that invocation are handled.
Issue: SPR-11540
Prior to this commit, CacheResolver could not be configured through
the XML namespace (i.e. cache:annotation-driven). This is now the
case.
Issue: SPR-11490
This commit adds the necessary infrastructure to handle exceptions
thrown by a cache provider in both Spring's and JCache's caching
abstractions.
Both interceptors can be configured with a CacheErrorHandler that
defines several callbacks on typical cache operations. In particular,
handleCacheGetError can be implemented in such a way that an
exception thrown by the provider is handled as a cache miss by the
caching abstraction.
The handler can be configured with both CachingConfigurer and the
XML namespace (error-handler property)
Issue: SPR-9275
Clean up compiler warnings in the tests of spring-context-support.
This commit:
* adds type parameters to all the types except `Cache` (mostly `List`
and `Map`)
* removes unused imports
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 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
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 ensures that QuartzSupportTests and its related
configuration are compatible with Quartz 2.1.7.
- Test jobs are now durable where required.
- Deleted legacy tests that attempted to use a Runnable instead of a
Job as a jobClass for a JobDetail.
- Replaced quartz-hsql.sql with current version for Quartz 2.1.7.
Issue: SPR-11630
Prior to this commit, the codebase was using a mix of log4j.xml
and log4j.properties for test-related logging configuration. This
can be an issue as log4j takes the xml variant first when looking
for a default bootstrap configuration.
In practice, some modules declaring the properties variant were
taking the xml variant configuration from another module.
The general structure of the configuration has also been
harmonized to provide a standard console output as well as an
easy way to enable trace logs for the current module.
This commit adds tests for TransactionAwareCacheDecorator. In
particular, the put/evict behaviour when the operation is invoked in
the course of Spring-managed transaction.
As a benefit over the "shared" flag, this allows for sharing a specific CacheManager in a system with potentially multiple CacheManagers involved, and it supports controlled shutdown by the EhCacheManagerFactoryBean that actually created the CacheManager.
Issue: SPR-11178
This new get variant not only allows for generically specifying the required value type; it also skips the ValueWrapper that the standard get method returns. Note that it is not possible to differentiate between non-existing cache entries and cached null values that way; for that purpose, the standard get variant needs to be used.
Issue: SPR-11061
Add temporary Assume.canLoadNativeDirFonts() method allowing failing
jasper report tests to be bypassed on OSX.
This should be revisited when JDK 8 is released.
Issue: SPR-10537
Specifically, EhCacheFactoryBean extends CacheConfiguration now and therefore inherits all configuration properties of the underlying EhCache version. This reduces the need for catching up with new EhCache properties on our side.
Issue: SPR-8258
Prior to this commit many test utility classes and sample beans were
duplicated across projects. This was previously necessary due to the
fact that dependent test sources were not shared during a gradle
build. Since the introduction of the 'test-source-set-dependencies'
gradle plugin this is no longer the case.
This commit attempts to remove as much duplicate code as possible,
co-locating test utilities and beans in the most suitable project.
For example, test beans are now located in the 'spring-beans'
project.
Some of the duplicated code had started to drift apart when
modifications made in one project where not ported to others. All
changes have now been consolidated and when necessary existing tests
have been refactored to account for the differences.
Conflicts:
spring-beans/src/test/java/org/springframework/beans/factory/ConcurrentBeanFactoryTests.java
spring-beans/src/test/java/org/springframework/beans/factory/support/BeanFactoryGenericsTests.java
spring-beans/src/test/java/org/springframework/beans/support/PagedListHolderTests.java
- Add TestGroup#LONG_RUNNING to distinguish from #PERFORMANCE, the
former being tests that simply take a long time vs the latter being
tests that are actually dependent on certain actions happening within
a given time window and are thefore CPU-dependent.
Issue: SPR-9984
Move code from spring-build-junit into spring-core/src/test along with
several other test utility classes. This commit removes the temporary
spring-build-junit project introduced in commit
b083bbdec7.
Fix deprecation compiler warnings by refactoring code or applying
@SuppressWarnings("deprecation") annotations. JUnit tests of
internally deprecated classes are now themselves marked as
@Deprecated.
Numerous EasyMock deprecation warnings will remain until the
migration to mockito can be completed.
Stephane Nicoll
Juergen Hoeller
Phillip Webb
Stephane Nicoll
Sam Brannen
Philippe Marschall
Phillip Webb
Phillip Webb
Chris Beams