-
Notifications
You must be signed in to change notification settings - Fork 37.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow programmatic registration of completion and error callbacks to transactional event listeners #24163
Comments
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Original ticket: spring-projects#24163
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Original ticket: spring-projects#24163
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Open questions: - Shall we use @TEL.value for the identifier instead of @TEL.id? @el has value already bound to event types to match. - Shall standard @EventListeners get identifiers as well? Original ticket: spring-projects#24163
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Open questions: - Shall we use @TEL.value for the identifier instead of @TEL.id? @el has value already bound to event types to match. - Shall standard @EventListeners get identifiers as well? Original ticket: spring-projects#24163
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Open questions: - Shall we use @TEL.value for the identifier instead of @TEL.id? @el has value already bound to event types to match. - Shall standard @EventListeners get identifiers as well? Original ticket: spring-projects#24163
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Open questions: - Shall we use @TEL.value for the identifier instead of @TEL.id? @el has value already bound to event types to match. - Shall standard @EventListeners get identifiers as well? Original ticket: spring-projects#24163
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Open questions: - Shall we use @TEL.value for the identifier instead of @TEL.id? @el has value already bound to event types to match. - Shall standard @EventListeners get identifiers as well? Original ticket: spring-projects#24163
Introduce TransactionalEventListenerMetadata that exposes metadata about ApplicationListeners derived from @TransactionalEventListener. That metadata allows registering completion callbacks and error handlers that will be triggered depending on the outcome of the invocation of the transactional event listener. Open questions: - Shall we use @TEL.value for the identifier instead of @TEL.id? @el has value already bound to event types to match. - Shall standard @EventListeners get identifiers as well? Original ticket: spring-projects#24163
I've got a complete cut ready now which I intend to commit ASAP. This is based on a |
Currently, event listeners bound to transaction commits, rollbacks or completion in general can only be used via the @TransactionalEventListener annotation. It would be nice if there was a way to programmatically register those via
context.addApplicationListener(…)
, pointing to a method, configuring the transaction phase to apply the listener in etc.After revisiting this with @jhoeller, here's the current state and derived ideas for what to improve on:
ApplicationListenerMethodTransactionalAdapter
is currently package protected and thus prevents programatic access to transactional event listeners as there's no type you can refer to even in instance of checks. We had the idea to introduce a public type thatALMTA
would extend / implement that exposes the following API:@TransactionalEventListener
or via the to be introduced programatic API….registerCompletionCallback(Consumer<ApplicationEvent>)
that will be called for every successfully completed invocation of the listener….registerErrorCallback(Consumer<Throwable>)
that will be called in case the listener threw an exception. If that callback is registered theThrowable
would not be propagated, so thatTransactionSynchronizationUtils.invokeAfterCompletion(…)
would not actually see theThrowable
and avoid the logging.ApplicationListenerMethodAdapter.processEvent(…)
to make sure the listener instance can be invoked explicitly. This is needed in the context of transactional even listeners as the already externally accessibleonApplicationEvent(…)
implements the event publication by registering a transaction synchronization, which does not immediately execute the listener.Most of this is driven by a prototypical event publication log implementation that makes sure that events handled by transactional event listeners do not get lost in case of exceptions occurring during the handling or unanticipated application shutdowns during that work. That work can be found here. The implementation currently relies on deep reflection inspection of framework internals and AOP usage to implement the log and log entry completion. That implementation would become significantly simpler.
Another aspect that makes this worthwhile is the general ability to use event listener registrations programmatically to avoid reflection and annotation detection overhead which in turn aligns with our functional bean registration API efforts.
The text was updated successfully, but these errors were encountered: