DefaultMessageListenerContainer doesn't start when initialize() is called previously, property, spring

amy

DefaultMessageListenerContainer doesn't start when initialize() is called in spring 3.0.5.  Whereas in spring 2.5, initialize() starts the container when the autoStart is set to true.

That's because Spring 3.0 introduced a new level of control for lifecycle. There is a SmartLifecycle interface that introduces the concept of a quot;phasequot; in combination with the 'autoStartup' property. In fact, for something like a DefaultMessageListenerContainer, it was previously possible to have it start quot;too earlyquot;; initialize() could be called on that instance *before* other resources (perhaps a DB to handle the input from a JMS Destination) were themselves initialized and started. Now, the startup happens after all beans are initialized yet still as part of the application context startup process. With the quot;phasequot; as a configurable value, it also means that different components can be explicitly ordered.

Hope that clarifies.
-Mark

So, should start command be called explicitly to start the container after initialize?

Not necessarily. If 'autoStartup' is true, it will start with the ApplicationContext. It just happens after initialization instead of during initialization.

I'm calling the DefaultMessageListenerConainer class in my code as below.  

DefaultMessageListenerConainer  listenerContainer = new DefaultMessageListenerConainer ();       listenerContainer.setMessageListener(localMessageL  istener);        listenerContainer.setAutoStartup(true);        listenerContainer.setRecoveryInterval(recoveryInte  rval.longValue());        listenerContainer.setConnectionFactory(cfMap.get(d  esignation));        listenerContainer.setDestination(destQueue);        listenerContainer.setConcurrentConsumers(queueConf  ig.getConsumers());                listenerContainer.initialize();

Well, if you're only dealing with it programmatically, then yes you would need to call start() yourself. The autoStartup property is what drives it within an ApplicationContext.

Thanks Mark.