DefaultMessageListenerContainer should not been autoconfigured with CachingConnectionFactory about spring-boot HOT 3 OPEN

OSS support for Spring Boot 2.7.x has ended so I'm afraid this won't change in Spring Boot 2.x.

If you want to use a caching connection factory with your JMS template but not with your message listener container, you could define either the template or the listener container yourself. The latter is probably the easier of the two:

@Bean
DefaultJmsListenerContainerFactory jmsListenerContainerFactory(
		DefaultJmsListenerContainerFactoryConfigurer configurer, ConnectionFactory connectionFactory) {
	DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
	configurer.configure(factory, ((CachingConnectionFactory)connectionFactory).getTargetConnectionFactory());
	return factory;
}

Spring Boot 3.x uses Spring Framework 6.x where the javadoc has been amended and the note softened quite a bit. That said, it still leans towards not using a CachingConnectionFactory with a listener container.

@jhoeller, what would you recommend here for Boot 3? I doubt that we'd change this in a maintenance release but we could consider unwrapping any caching connection factory in a new minor.

from spring-boot.

Yes, unwrapping is easy. It just breaks reconnecting after broker restart badly.

from spring-boot.

I just reviewed the javadoc change. The change of documentation relating to dynamic scaling might be right. What should be stressed: the CachingConnectionFactory breaks (might be depending on type underlying ConnectionFactory) recovering from broker outage. This is clearly reproducable. In our case it affected the system badly leading to outage of our production system and unessesary downtime affecting our customers.

from spring-boot.