DefaultMessageListenerContainer reconnecting at startup

[bhusted]

To ensure the application can recover when the JMS server down at startup, my application code will establish a JMS connection before attempting to load the DefaultMessageListenerContainer from the spring context. I have set lazy-init to true on all of the beans including the AbstractJNDI queue bean.

However, when I start my application and the JMS server is down, I get errors since the application context trys to resolve the bean ref to the queue and fails because the JMS server is down.

Does the fact that I have a bean ref to the JNDI queue within the container force it to load even if I have every bean set to lazy initialize?

Perhaps there is a better way to solve this problem of a JMS server not being available on startup?

[nkhadakk]

have you tried setting the property 'recoveryInterval' for DMLC ? This will cause DMLC to keep trying to resolve Connections/Destinations at that interval.

[denis.zhdanov]

It seems that you injected you container to another bean which is not lazily instantiated. In this case 'lazy-init' attribute is ignored and container object is created at application context initialization. You can check this easily by writing a simple application with the only bean of class DML with 'lazy-init' attribute set to true. It must not be created at context startup initialization.