Previously, cache transaction managers may be retained outside the
boundaries of an application context with AspectJ since an aspect is
basically a singleton for the current class loader.
This commit adds a "clearTransactionManagerCache" that is similar to the
"clearMetadataCache" introduced in CacheAspectSupport: whenever the
context is disposed, the cache is cleared to remove any reference to a
transaction manager defined by that context.
Issue: SPR-12518
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
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
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
The removal of whitespace to the *.aj files made in 1762157 cause
NoSuchMethodError for code compiled against previous versions of
spring-aspects due to a bug in AspectJ (see SPR-10178 for details).
This commit reverts all the whitespace changes made in 1762157 which
resolves the NoSuchMethodErrors.
Issue: SPR-10178
- Support external Javadoc links using Gradle's javadoc.options.links
- Fix all other Javadoc warnings, such as typos, references to
non-existent (or no longer existent) types and members, etc,
including changes related to the Quartz 2.0 upgrade (SPR-8275) and
adding the HTTP PATCH method (SPR-7985).
- Suppress all output for project-level `javadoc` tasks in order to
hide false-negative warnings about cross-module @see and @link
references (e.g. spring-core having a @see reference to spring-web).
Use the `--info` (-i) flag to gradle at any time to see project-level
javadoc warnings without running the entire `api` task. e.g.
`gradle :spring-core:javadoc -i`
- Favor root project level `api` task for detection of legitimate
Javadoc warnings. There are now zero Javadoc warnings across the
entirety of spring-framework. Goal: keep it that way.
- Remove all @link and @see references to types and members that exist
only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+
respectively. This is necessary because only one version of each of
these dependencies can be present on the global `api` javadoc task's
classpath. To that end, the `api` task classpath has now been
customized to ensure that the Servlet 3 API and Hibernate Core 4 jars
have precedence.
- SPR-8896 replaced our dependency on aspectjrt with a dependency on
aspectjweaver, which is fine from a POM point of view, but causes
a spurious warning to be emitted from the ant iajc task that it
"cannot find aspectjrt on the classpath" - even though aspectjweaver
is perfectly sufficient. In the name of keeping the console quiet, a
new `rt` configuration has been added, and aspectjrt added as a
dependency to it. In turn, configurations.rt.asPath is appended to
the iajc classpath during both compileJava and compileTestJava for
spring-aspects.
Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896
Commit 5327a7a37d moved
@EnableSpringConfigured from beans.factory.aspectj =>
context.annotation within the spring-aspects module. This resolved a
package cycle but had the side-effect of causing a "split package" [1]
problem between spring-context and spring-aspects in OSGi-based
classloader environments because the context.annotation package now
exists in both modules.
The simplest and best solution from an OSGi perspective is to relocate
@EnableSpringConfigured and its supporting SpringConfiguredConfiguration
class into a new package. This commit moves both these types into
context.annotation.aspectj, following convention with other such
"aspectj"-qualified packages in the spring-aspects module.
As with the previous move, it is presumed this change will be low-impact
as the "spring-configured" approach to domain object injection is a
niche feature to begin with, and @EnableSpringConfigured has existed in
its current location only since 3.1.2 and this change is being made in
time for 3.1.3.
[1]: http://wiki.osgi.org/wiki/Split_Packages
Issue: SPR-9811, SPR-9441
@EnableSpringConfigured and its @Import'ed
SpringConfiguredConfiguration @Configuration class inadvertently
established a package cycle between beans.factory.aspectj and
context.annotation due to SpringConfiguredConfiguration's
dependency on annotations such as @Configuration, @Bean and @Role.
This commit fixes this architecture bug by moving
@EnableSpringConfigured and SpringConfiguredConfiguration from the
beans.factory.aspectj package to the context.annotation package where
they belong.
This change is assumed to be very low impact as @EnableSpringConfigured
was introduced in 3.1.0 and relocation is happening as quickly as
possible in 3.1.2. @EnableSpringConfigured is assumed to be infrequently
used at this point, and for those that are the migration path
is straightforward. When upgrading from Spring 3.1.0 or 3.1.1, update
import statements in any affected @Configuration classes to reflect the
new packaging.
Issue: SPR-9441
Prior to this change, Spring's @Async annotation support was tied to a
single AsyncTaskExecutor bean, meaning that all methods marked with
@Async were forced to use the same executor. This is an undesirable
limitation, given that certain methods may have different priorities,
etc. This leads to the need to (optionally) qualify which executor
should handle each method.
This is similar to the way that Spring's @Transactional annotation was
originally tied to a single PlatformTransactionManager, but in Spring
3.0 was enhanced to allow for a qualifier via the #value attribute, e.g.
@Transactional("ptm1")
public void m() { ... }
where "ptm1" is either the name of a PlatformTransactionManager bean or
a qualifier value associated with a PlatformTransactionManager bean,
e.g. via the <qualifier> element in XML or the @Qualifier annotation.
This commit introduces the same approach to @Async and its relationship
to underlying executor beans. As always, the following syntax remains
supported
@Async
public void m() { ... }
indicating that calls to #m will be delegated to the "default" executor,
i.e. the executor provided to
<task:annotation-driven executor="..."/>
or the executor specified when authoring a @Configuration class that
implements AsyncConfigurer and its #getAsyncExecutor method.
However, it now also possible to qualify which executor should be used
on a method-by-method basis, e.g.
@Async("e1")
public void m() { ... }
indicating that calls to #m will be delegated to the executor bean
named or otherwise qualified as "e1". Unlike the default executor
which is specified up front at configuration time as described above,
the "e1" executor bean is looked up within the container on the first
execution of #m and then cached in association with that method for the
lifetime of the container.
Class-level use of Async#value behaves as expected, indicating that all
methods within the annotated class should be executed with the named
executor. In the case of both method- and class-level annotations, any
method-level #value overrides any class level #value.
This commit introduces the following major changes:
- Add @Async#value attribute for executor qualification
- Introduce AsyncExecutionAspectSupport as a common base class for
both MethodInterceptor- and AspectJ-based async aspects. This base
class provides common structure for specifying the default executor
(#setExecutor) as well as logic for determining (and caching) which
executor should execute a given method (#determineAsyncExecutor) and
an abstract method to allow subclasses to provide specific strategies
for executor qualification (#getExecutorQualifier).
- Introduce AnnotationAsyncExecutionInterceptor as a specialization of
the existing AsyncExecutionInterceptor to allow for introspection of
the @Async annotation and its #value attribute for a given method.
Note that this new subclass was necessary for packaging reasons -
the original AsyncExecutionInterceptor lives in
org.springframework.aop and therefore does not have visibility to
the @Async annotation in org.springframework.scheduling.annotation.
This new subclass replaces usage of AsyncExecutionInterceptor
throughout the framework, though the latter remains usable and
undeprecated for compatibility with any existing third-party
extensions.
- Add documentation to spring-task-3.2.xsd and reference manual
explaining @Async executor qualification
- Add tests covering all new functionality
Note that the public API of all affected components remains backward-
compatible.
Issue: SPR-6847
In anticipation of substantive changes required to implement @Async
executor qualification, the following updates have been made to the
components and infrastructure supporting @Async functionality:
- Fix trailing whitespace and indentation errors
- Fix generics warnings
- Add Javadoc where missing, update to use {@code} tags, etc.
- Avoid NPE in AopUtils#canApply
- Organize imports to follow conventions
- Remove System.out.println statements from tests
- Correct various punctuation and grammar problems
Juergen Hoeller
Stephane Nicoll
Janning Vygen
Juergen Hoeller
Stephane Nicoll
Sam Brannen
Chris Beams
Rob Winch
Phillip Webb