@EventListener annotated bean cannot be removed from the ApplicationEventMulticaster
See original GitHub issueAffects: 2.4.3
According to the JavaDoc of the ApplicationEventMulticaster
I was expecting to be able to remove and/or add ApplicationListeners at runtime.
This currently does not work for @EventListener
annotated methods, which apparently lead to a ApplicationListenerMethodAdapter
instance at runtime.
Would be great, if we could remove this listener as well, either by
- making the Adapter instance injectable and then remove it with
multicaster.removeApplicationListener()
, or - giving the Adapter instance a well defined bean name and remove it with
multicaster.removeApplicationListenerBean()
I’ve included a small demo app with a failing test to illustrate what I’m trying to achieve:
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (5 by maintainers)
Top Results From Across the Web
Dynamically remove a @EventListener in Spring
How can I get hold of the name of this bean, so that I can remove the bean with the ApplicationEventMulticaster ? eventMulticaster....
Read more >Event Handling With Spring Framework
Spring 4.1 introduced @EventListener , annotation driven event Listener which removed all the complexities of defining your EventListner.
Read more >EventListener (Spring Framework 6.0.2 API)
Annotation that marks a method as a listener for application events. If an annotated method supports a single event type, the method may...
Read more >2 Reasons of org.springframework.beans.factory ...
At the startup, when the Spring framework initializes the system by creating objects and their dependencies depending upon @Autowired annotation or spring ...
Read more >org.springframework.context.event ...
ApplicationEventMulticaster maven / gradle build tool code. ... @param listenerBeanName the name of the listener bean to remove * @see ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I’ve introduced an
ApplicationEventMulticaster.removeApplicationListeners(Predicate<ApplicationListener<?>>)
method in combination withApplicationListener.getListenerId()
, derived from the optional@EventListener.id
attribute and defaulting to the signature of the annotated method. The latter two have been pulled up fromTransactionalApplicationListener
and@TransactionalEventListener
where they had similar semantics already (recently introduced in 5.3, so not widely known).I hope this works for your use case, e.g.:
removeApplicationListeners(l -> l.getListenerId().startsWith("myrootpackage.mymodule"))
I’ve revised this a bit to only expose the
getListenerId()
method onSmartApplicationListener
(and also onGenericApplicationListener
which derives from it now), avoiding potential conflicts with plainApplicationListener
implementations that happen to implement other interfaces as well (keeping the base interface as minimal as possible).This means that a downcast will be necessary, I hope that’s still not too bad: