AbstractJmsListeningContainer should provide an easy way to start the container after the ApplicationContext has been fully initialized [SPR-4716]

[spring-projects-issues]

Lari Hotari opened SPR-4716 and commented

AbstractJmsListeningContainer should provide an easy way to start the container after the ApplicationContext has been fully initialized.
The current "autoStartup" feature calls start() in the afterPropertiesSet method. That is too early for some applications which are dependent on BeanPostProcessors etc.. Maybe the "auto startup" should happen after a ContentRefreshedEvent?

---

Affects: 2.5.3

Referenced from: commits 40720ab, d96bea9

1 votes, 4 watchers

[spring-projects-issues]

Mark Fisher commented

We can probably just have AbstractMessageListenerContainer implement ApplicationListener and defer the auto-startup to when the ContextRefreshedEvent is received.

If Spring eventually provides a way to have the container automatically call start() on all Lifecyle instance (as it does for stop() when the context closes), that could replace the ContextRefreshedEvent-driven technique.

[spring-projects-issues]

Mark Fisher commented

Committed the initial resolution: auto-start now occurs upon receiving a ContextRefreshedEvent instead of happening upon initialization.

Other changes in RC2 might lead to some changes within the scope of a more general solution.

[spring-projects-issues]

Mark Fisher commented

This same issue applies to GenericMessageEndpointManager.

[spring-projects-issues]

Mark Fisher commented

Refactored GenericMessageEndpointManager as well.

[spring-projects-issues]

Mark Fisher commented

This is now driven by the DefaultLifecycleProcessor so that the listener container does not have to implement ApplicationListener anymore. The autoStartup flag is checked upon ApplicationContext refresh and if "true", it will be started.