Spring 3.0 lazy-init not honoured for DefaultMessageListenerContainer?

Question

I've setup a spring config for JMS. Things work fine, except I can't seem to get it to lazy load (notice the default-lazy-init true in the code below). If I comment out the jmsContainer(DMLC) from my config below, lazy loading works as expected. Otherwise, it will instantiate the DMLC, which in turn creates the queue and connection factory.

What am I missing?

jmsContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:p="http://www.springframework.org/schema/p"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"
       default-lazy-init="true">

    <bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
        <property name="environment">
            <props>
                <prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop>
                <prop key="java.naming.provider.url">t3:localhost:7001</prop>
            </props>
        </property>
    </bean>

    <bean id="queue" class="org.springframework.jndi.JndiObjectFactoryBean"
          p:jndiTemplate-ref="jndiTemplate" p:jndiName="jms/queue"/>

    <bean id="connectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean"
          p:jndiTemplate-ref="jndiTemplate" p:jndiName="jms/connectionfactory"/>

    <bean id="jmsDestinationResolver" class="org.springframework.jms.support.destination.JndiDestinationResolver"
        p:jndiTemplate-ref="jndiTemplate" p:cache="true" />

    <bean id="jmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"
          p:autoStartup="false"
          p:destination-ref="queue"
          p:destinationResolver-ref="jmsDestinationResolver"
          p:connectionFactory-ref="connectionFactory"
          p:messageListener-ref="queueListener" />

    <bean id="queueListener" class="com.blah.QueueListener"/>


</beans>

And the test I'm using to drive it, DummyTest.java:

package blah;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:jmsContext.xml")
public class DummyTest {

    @Test
    public void shouldDoSomething() {

    }

}

When jmsContainer is commented out, the test above passes. Otherwise, I get this:

java.lang.IllegalStateException: Failed to load ApplicationContext
Caused by: org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'jmsContainer' defined in class path resource [com/blah/config/jmsContext.xml]: 
Cannot resolve reference to bean 'connectionFactory' while setting bean property 'connectionFactory'; 
nested exception is org.springframework.beans.factory.BeanCreationException: 
Error creating bean with name 'connectionFactory' defined in class path resource [com/blah/config/jmsContext.xml]: 
Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: 
Exception in lookup.: `jms/connectionfactory' could not be found. 
[Root exception is weblogic.corba.cos.naming.NamingContextAnyPackage.NotFound: IDL:weblogic/corba/cos/naming/NamingContextAny/NotFound:1.0]

The "connectionFactory" bean gets instantiated as a dependency of "jmsContainer" and it fails. With "jmsContainer" commented out, "connectionFactory" does not get instantiated.

The jms code works fine, but I have renamed my JNDI names on purpose so I can see when things get started.

Offstage

Are you absolutely sure it's starting up? What's the evidence? Can you incorporate that evidence in your test? – Gaulin

For (my) future prosperity: Bean creation and listener container startup are different things. p:autoStartup="false" will stop the listener container from starting up, though its bean references must resolve. If you have other beans like JmsMessageDrivenEndpoint which implement SmartLifeCycle, then those must also have autoStartup="false", other wise they'll start up the listener container – Gold

+1 for isAutoStartup mention. This was my problem when attempting to load up SimpleMessageContextListener for AMQP. – Androsphinx

Answer 1

OK, this is pretty obscure, but DefaultMessageListenerContainer implements the Lifecycle interface, and beans that implement this are tied into the context's own lifecycle - when the context starts up, Lifecycle-implementing beans are initialised and started. This means that your lazy-init config is essentially ignored.

Gaulin

Actually it's the SmartLifecycle interface: static.springsource.org/spring/docs/3.0.x/javadoc-api/org/…. It needs to be instantiated so Spring can call isAutoStartup to figure whether it needs to be started. – Offstage

Answer 2

The solution is to use autoStartup to false. See the code below.

<bean id="listenerContainer"
    class="org.springframework.jms.listener.DefaultMessageListenerContainer">
     ........
    <property name="autoStartup" value="false"/>
</bean>

~Shyam

Zumstein