Issue 1:
Christopher Nichols opened SPR-7584 and commented

Lightly wordsmithing the original post from the forum.

"We recently upgraded from Spring 2.5.6 to Spring 3.0.2. We had "default-lazy-init" set to true for the majority of the beans and didn't change those settings with our Spring upgrade. However, we found that the lazy-init behavior changed between Spring 2.5 and 3.0.

With 2.5, the beans flagged for lazy-init are truly lazily initialized, i.e. they are initialized on demand after the Spring Application Context instantiation is complete.

With 3.0, the Spring container attempts to eagerly initiate all beans including the ones flagged for lazy-init, as part of the Spring Application Context instantiation step. If any bean flagged for lazy-init throws exception during initialization, the exception will be ignored and Spring Application Context instantiation will continue on..." See the forum post for more details.

The upgrade guide doesn't have any details about lazy-init changing the way it functions. As such, this looks a bug.

Affects: 3.0.2

Reference URL: http://forum.springsource.org/showthread.php?p=318697#post318697

Issue Links:

#12992 Lazy-init beans are unnecessarily created during the candidate determination process ("duplicates")

Issue 2:
gobreak opened SPR-2181 and commented

I have tried using JBossMQ and ActiveMQ to receive async message by DefaultMessageListenerContainer.

Transaction Manager from JBoss are used and set properly as a bean property for DefaultMessageListenerContainer.

To trigger the XA rollback, I throw a runtime exception in the onMessage() callback of the MessageListener.

However, the message is still commit.

The bean setting:

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">

<property name="userTransaction" ref="userTransaction"/>

</bean>

<bean id="userTransaction"

class="org.springframework.jndi.JndiObjectFactoryBean">

<property name="jndiName">

<value>java:comp/UserTransaction</value>

</property>

</bean>

<bean id="listenerContainer"
class="org.springframework.jms.listener.DefaultMessageListenerContainer">
<property name="connectionFactory" ref="XAJmsConnectionFactory" />
<property name="destination" ref="XADestination" />
<property name="messageListener" ref="coreInboundBeanImpl" />
<property name="transactionManager" ref="transactionManager"/>
</bean>

Finally, I needed to extend DefaultMessageListenerContainer and override the receive() method using JMSTemplate instead of the message consumer as follow:

public Message receive(long timeOut) throws JMSException{

template.setConnectionFactory(getConnectionFactory());

template.setDefaultDestination(getDestination());

template.setReceiveTimeout(timeOut);

if (getMessageSelector() == null || "".equals(getMessageSelector().trim()))

return template.receive(getDestination());

else

return template.receiveSelected(getDestination(), getMessageSelector());

}

I use JMSTemplate because I find it performs XA without any noticed problem.

Using the above implementation can successfully rollback as well as commit the message. I am seeking for better solution on this topic.

Affects: 2.0 RC1

Issue Links:

#6784 Cannot do XA Rollback Using DefaultMessageListenerContainer on JBoss ("duplicates")