This commits complements 222d2b1 for another required dependency.
javax.persistence.Entity was previously required, regardless of which
aspects were actually used by the project. It is now optional and will
not break the build if it is not present. Note that the side effect is that
AnnotationDrivenStaticEntityMockingControl is disabled as well if the
JPA API is not available.
Issue: SPR-6819
Prior to this commit, a project using compile time weaving upgrading to
4.1 was forced to add spring-context-support and the jcache API in order
to build. This problem is not new really: spring-aspects holds all
aspects provided by the framework and they all are evaluated when
compiling. 4.1 just happens to define a new aspect that requires extra
dependencies.
This commit uses a new annotation of AspectJ 1.8.3. When @RequiredTypes
is added on an aspect, it is evaluated only if the classes defined on the
annotation are actually present. If they are not, the aspect is disabled
and does not break the build.
Issue: SPR-12163
Prior to this commit, only @Async annotated methods with proxy style
had an explicit support for ListenableFuture. This commit brings that
support to AspectJ as well.
Issue: SPR-12092
Prior to this commit, only @Async annotated methods with proxy style
had their custom uncaught exception handler applied. This commit
harmonizes the configuration so that AspectJ applies that behaviour as
well.
Issue: SPR-12090
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, 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
It is now possible to specify the CacheManager to use per operation.
The related cache annotation now has an extra attribute that defines
the name of the CacheManager bean to use. The cache manager that
was previously used is therefore a 'default' cache manager (i.e. the
one to use if no custom cache manager has been set on the operation).
Issue: SPR-8696
This commit adds an extra parameter to the base @Cache method
annotations: keyGenerator. This parameter holds the name of the
KeyGenerator bean to use to compute the key for that specific
caching endpoint.
This gives therefore a third way to customize the key. These are:
1. Default KeyGenerator (global for all endpoints)
2. The 'key' attribute of the annotation, giving the SpEL expression to use
3. The 'keyGenerator' attribute of the annotation
The annotation attributes are therefore exclusive. Trying to specify
them both will result in an IllegalStateException.
The KeyGenerator to use for a given operation is cached on startup
so that multiple calls to it does not resolve the instance to use over and
over again.
Issue: SPR-10629
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 introduces static verify() and reset() methods in
AnnotationDrivenStaticEntityMockingControl for programmatic control
on the mock.
Issue: SPR-11395
This commit improves the test coverage for AbstractMethodMockingControl
by introducing tests that verify expected behavior for:
- reentrant method invocations via public methods
- reentrant method invocations via private methods
- test methods that do not set expectations or invoke playback()
- test methods that throw exceptions
For a more complete discussion of "after" vs. "after returning" advice
within AbstractMethodMockingControl, see the Javadoc in the tests.
This commit fixes the off-by-one regression accidentally introduced in
commit 55961544a7.
Specifically, this fix ensures that the correct recorded call is
indexed in the 'calls' list in the implementation of
AbstractMethodMockingControl.Expectations.nextCall().
In addition, this commit improves the Javadoc for
AbstractMethodMockingControl, @MockStaticEntityMethods, and
AnnotationDrivenStaticEntityMockingControl and introduces a proper
toString() implementation for the internal Expectations.Call class in
AbstractMethodMockingControl. Furthermore, code from the obsolete
Delegate test class has been inlined in
AnnotationDrivenStaticEntityMockingControlTests.
Issue: SPR-11385, SPR-10885
Prior to this commit several test classes named "*Test" were not
recognized as tests by the Gradle build. This is due to the configured
inclusion of '**/*Tests.*' which follows Spring's naming convention for
test classes.
This commit addresses this issue by:
- Renaming real test classes consistently to "*Tests".
- Renaming internal test classes to "*TestCase".
- Renaming @WebTest to @WebTestStereotype.
- Disabling broken tests in AnnoDrivenStaticEntityMockingControlTest.
- Modifying the Gradle build configuration so that classes ending in
either "*Tests" or "*Test" are considered test classes.
Issue: SPR-11384
Update `CacheAspectSupport` to expand any var-arg parameters before
calling `KeyGenerator` implementations. Prior to this commit var-args
would be passed to `KeyGenerator` implementations as a nested array,
often causing the same key to be generated regardless of the arguments.
Issue: SPR-10870
Allow the @CachePut 'key' SpEL to refer to the result of the method call
via a '#result' variable.
This change is particularly useful when working with JPA entities that
have generated @Id values since the ID will often not be available
until the entity has been saved.
Issue: SPR-10664
ASM has been patched to accept 1.8 bytecode simply through removing an assertion. As a consequence, we have an embedded copy of the ASM sources now instead of jarjar'ing the original ASM jar. The sources originate from ASM 4.1; for CGLIB 3.0 compatibility, a further assertion has been removed.
Issue: SPR-9639
Previously we had restored the whitespace for *.aj files in 6888a6f28
to avoid a but in aspectj.
We have updated to the latest version of apsectj and restored the
changes in commit 6888a6f28 which included a significant cleanup of
whitespace.
Issue: SPR-10208
Effectively, AbstractTransactionAspect got refactored into around advice, reusing former TransactionInterceptor code which now lives in slightly generalized form in TransactionAspectSupport, and using a workaround for rethrowing checked exceptions.
Issue: SPR-9268
Allow @Cachable, @CachePut and equivalent XML configuration to provide
a SpEL expression that can be used to veto putting an item into the
cache. Unlike 'condition' the 'unless' parameter is evaluated after
the method has been called and can therefore reference the #result.
For example:
@Cacheable(value="book",
condition="#name.length < 32",
unless="#result.hardback")
This commit also allows #result to be referenced from @CacheEvict
expressions as long as 'beforeInvocation' is false.
Issue: SPR-8871
Stephane Nicoll
Juergen Hoeller
Janning Vygen
Stephane Nicoll
Sam Brannen
Phillip Webb
Phillip Webb
Rob Winch
Chris Beams