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
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
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
While we've had basic Quartz 2.2 support before, a few details were missing:
* LocalDataSourceJobStore's ConnectionProvider adapters need to provide an empty implementation of Quartz 2.2's new initialize method.
* SchedulerFactoryBean's "schedulerContextMap" needs to be explicitly declared with String keys, otherwise it can't be compiled against Quartz 2.2 (forward compatibility once we're dropping Quartz 1.x support). This doesn't hurt against older Quartz versions either, since the keys need to be Strings anyway.
Issue: SPR-11284
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
Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.
Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.
Issue: SPR-11064
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
Introduced DefaultManagedTaskExecutor, DefaultManagedTaskScheduler and DefaultManagedAwareThreadFactory classes, revised related javadoc, and deprecated unsupported JBossWorkManagerTaskExecutor in favor of JSR-236 setup on WildFly 8.
Issue: SPR-8195
Unfortunately, the JCache API changed quite a bit since 0.6. We're building against a snapshot of JCache 0.11 now, tracking its way to final after the Public Review Ballot.
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
