Update the application event listener infrastructure to support events
that are processed according to a transactional phase.
Introduce EventListenerFactory that can be implemented to provide support
for additional event listener types. TransactionalEventListener is a new
annotation that can be used in lieu of the regular EventListener. Its
related factory implementation is registered in the context automatically
via @EnableTransactionManagement or <tx:annotation-driven/>
By default, a TransactionalEventListener is invoked when the transaction
has completed successfully (i.e. AFTER_COMMIT). Additional phases are
provided to handle BEFORE_COMMIT and AFTER_ROLLBACK events.
If no transaction is running, such listener is not invoked at all unless
the `fallbackExecution` flag has been explicitly set.
Issue: SPR-12080
Fix a regression introduced by 961574bd17 that prevents a proper lookup
of the default transaction manager by name as the absence of a qualifier
is represented by an empty string (passing the faulty null check).
Issue: SPR-12577
One more (and hopefully last) attempt at making sure
determineTransactionManager does not break existing use cases.
This commit prevents any lookup if no transaction attributes are set
which is more compliant with the original version and prevents a lookup
if a non existing bean name is provided explicitly (as it can be the case
with Spring Boot).
Issue: SPR-12541
The fix in cec26e9 for SPR-12541 actually introduced a regression
when the interceptor is enabled on a method that does not require any
transaction. In such a case we try to locate the default
PlatformTransactionManager instead of just returning what we have (that
is null).
This commit updates the determineTransactionManager condition again to
take that use case into account again.
Issue: SPR-12541
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
SPR-11954 introduced a regression that when the "default" transaction
manager is cached, qualified transaction managers are not taken into
account anymore.
This commit rework the "determineTransactionManager" condition to
favor qualifier and "named" transaction managers. If none of these apply,
the default transaction manager is used as it should.
Also reworked the caching infrastructure so that a single cache holds
all transaction manager instances.
Issue: SPR-12541
This commit adds the missing 4.1 XSDs for the following components:
* spring-aop
* spring-context
* spring-jee
* spring-lang
* spring-tx
* spring-util
These are strictly identical to the definition of the 4.0 XSDs.
Issue: SPR-11990
Prior to this commit, cache operations mentioning a qualifier led to
a lookup for the same PlatformTransactionManager over and over again.
The same applied when a transactionManager bean name was specified on
the interceptor.
This commit adds a cache to store the reference of such transaction
managers. As a convenience, the default PlatformTransactionManager is
also initialized if it has not been through configuration.
Issue: SPR-11954
This commit adds a test that reproduces the behaviour described in
SPR-11915 and validates that the fix introduced in f8b6114440 works
as expected.
Issue: SPR-11915
Clean up compiler warnings in the tests of spring-tx. This commit
adds type parameters to all the types (mostly `List` and `Map`). In
addition it uses Java 5 autoboxing to get rid of several `new Integer`
(except in cases where it's needed).
After this commit the only warnings in spring-tx left are in
`TransactionAttributeSourceTests`` that code would never compile with
generics.
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.
Also simplified cache key 'hashCode' implementation, relying on 'equals' to differentiate between same method on different target classes.
Issue: SPR-11267
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
The tests introduced in this commit demonstrate the current lacking
support for composable stereotypes on interfaces (using @Transactional)
as a concrete example.
Issue: SPR-11108
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
Update MatchAlwaysTransactionAttributeSource.getTransactionAttribute
to allow a null method argument. Passing a null method is not
recommended and is not indicated as valid in the Javadoc, however,
this was allowed in previous versions of Spring.
Issue: SPR-11048
In particular, do not apply them to GroovyObject methods and other kinds of synthetic methods in language runtimes. The only exception are bridge methods since those do eventually point to a user-level generic method.
Issue: SPR-10803
Stephane Nicoll
Juergen Hoeller
Sam Brannen
Stephane Nicoll
Philippe Marschall
Phillip Webb