Previously, the exception-handler attribute was not taken care of when
task:annotation-driven is used in AspectJ mode. This commit provides the
expected behavior.
Issue: SPR-12619
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
Add support for annotation-based event listeners. Enabled automatically
when using Java configuration or can be enabled explicitly via the
regular <context:annotation-driven/> XML element. Detect methods of
managed beans annotated with @EventListener, either directly or through
a meta-annotation.
Annotated methods must define the event type they listen to as a single
parameter argument. Events are automatically filtered out according to
the method signature. When additional runtime filtering is required, one
can specify the `condition` attribute of the annotation that defines a
SpEL expression that should match to actually invoke the method for a
particular event. The root context exposes the actual `event`
(`#root.event`) and method arguments (`#root.args`). Individual method
arguments are also exposed via either the `a` or `p` alias (`#a0` refers
to the first method argument). Finally, methods arguments are exposed via
their names if that information can be discovered.
Events can be either an ApplicationEvent or any arbitrary payload. Such
payload is wrapped automatically in a PayloadApplicationEvent and managed
explicitly internally. As a result, users can now publish and listen
for arbitrary objects.
If an annotated method has a return value, an non null result is actually
published as a new event, something like:
@EventListener
public FooEvent handle(BarEvent event) { ... }
Events can be handled in an aynchronous manner by adding `@Async` to the
event method declaration and enabling such infrastructure. Events can
also be ordered by adding an `@Order` annotation to the event method.
Issue: SPR-11622
Update the event publishing infrastructure to support generics-based
events, that is support ApplicationListener implementations that define
a generic event, something like:
public class MyListener
implements ApplicationListener<GenericEvent<String>> { ... }
This listener should only receive events that are matching the generic
signature, for instance:
public class StringEvent extends GenericEvent<String> { ... }
Note that because of type erasure, publishing an event that defines the
generic type at the instance level will not work. In other words,
publishing "new GenericEvent<String>" will not work as expected as type
erasure will define it as GenericEvent<?>.
To support this feature, use the new GenericApplicationListener that
supersedes SmartApplicationListener to handle generics-based even types via
`supportsEventType` that takes a ResolvableType instance instead of the
simple Class of the event. ApplicationEventMulticaster has an additional
method to multicast an event based on the event and its ResolvableType.
Issue: SPR-8201
Previously, one could only set the list of bean names to exclude from
auto-detection and there was no way to add additional bean names.
MBeanExporter now exposes a addExcludedBean method that can be invoked
during the initialization phase to add bean names to ignore.
Issue: SPR-12686
Move MethodCacheKey and related classes to the expression package so that
other parts of the framework can benefit ot it.
CacheExpressionEvaluator is a base class that can be used to cache SpEL
expressions based on its annotation source (i.e. method). Sub-classing
that base class provides a simple to use API to retrieve Expression
instances efficiently.
Issue: SPR-12622
This commit overhauls several of the tests that interact with an
MBeanServer with the goal of increasing the reliability of these tests.
- MBeanClientInterceptorTests now uses JUnit "assumptions" instead of
preemptively returning from test methods, thus allowing such methods
to be properly marked as "ignored" instead of "passed".
- MBeanClientInterceptorTests now uses JUnit's support for expected
exceptions where appropriate.
- MBeanClientInterceptorTests and RemoteMBeanClientInterceptorTests now
use Spring's SocketUtils to find an available TCP port when starting
an MBeanServer instead of aborting the tests when the default JMX
port is not available.
Issue: SPR-12601
Commit 65d163e changed the textual message of an exception thrown by
ScheduledAnnotationBeanPostProcessor.afterSingletonsInstantiated(), and
this in turn caused the withAmbiguousTaskSchedulers_andSingleTask()
method in EnableSchedulingTests to start failing (albeit only during
'Performance' builds).
This commit updates the assertion to match the current implementation of
ScheduledAnnotationBeanPostProcessor.
Previously, if a bean has a scoped proxy and is annotated to be exposed
to the JMX domain, both the scoped proxy and the target instance were
exposed in the JMX domain, resulting in a duplicate entries. Worse, if
such bean defines an explicit name, the application wouldn't start
because of a name conflict.
This commit deals explicitely with scoped proxy and make sure to only
expose the relevant bean.
Issue: SPR-12529
Previously, any @Configuration class was enhanced to namely implement
DisposableBean in order to remove static callbacks that were registered
for that class. This leads to problem if an ApplicationContext is created
and destroyed within the lifecycle on another ApplicationContext in the
same class loader.
It turns out that the destruction callback is no longer necessary as the
interceptors are now stateless: the VM is free to reclaim any of those if
necessary.
Issue: SPR-12445
The removed test testConfigFileParsingErrorWhenNamedBeans() could cause
a groovyc compilation error, for example when using latest IntelliJ IDEA.
Issue: SPR-12435
Prior to this commmit, any configuration class holding a CacheManager
bean would be eagerly instantiated. This is because the
CacheConfiguration infrastructure requests all beans of type
CacheManager.
This commit defers the resolution of the CacheManager as late
as possible.
Issue: SPR-12336
Refine the logic introduced in commit 71c6eb2b so that additional
imported @Configuration classes are not considered as candidates if
they have already been parsed.
Issue: SPR-12233
Refine property source ordering so that sources already contained in the
environment remain before those added by @PropertySource annotations.
Issue: SPR-12198
Update JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable() to
call `getEnvironment()` on the `InitialContext` in order to actually
trigger a NamingException if JNDI is not available.
Issue: SPR-12223
Update ImportRegistry to track all import registrations that occur
against an importing class (rather than just keeping the last). In
addition, prune imported classes from the registry when a configuration
class is removed during the REGISTER_BEAN ConfigurationPhase.
This update prevents incorrect metadata from being injected into an
ImportAware class which is imported twice by different configurations
classes (when one of the configuration classes will be ultimately skipped
due to a @Condition).
Issue: SPR-12128
