See https://github.com/spring-projects/spring-framework/issues/28009#issuecomment-1031857962
Rather than recommending that developers call configurer.configure(listenerFactory, connectionFactory) then undo the transaction manager with setTransactionManager(null) we should offer a version that doesn't set it in the first place.
Comment From: philwebb
The org.springframework.boot.docs.howto.messaging.disabletransactedjmssession.MyJmsConfiguration Kotlin and Java samples will need to be updated after the fix. The @Suppress("NULLABILITY_MISMATCH_BASED_ON_JAVA_ANNOTATIONS") annotation should also be removed from the Kotlin sample.
Comment From: wilkinsona
It would work without any new public API if we set the transaction manager on the configure to null before calling configure. That feels more flexible to me than a new configure variant, however, the configurer's a bean so we shouldn't really mutate it. Perhaps it should be in prototype scope like RestTemplateBuilder?
Comment From: snicoll
I am not sure we should do anything. DefaultJmsListenerContainerFactoryConfigurer takes a JtaTransactionManager on purpose as a strong signal you need to use distributed transactions. If you don't use JTA, then these are usually the regular sessionTransacted thing, which is the recommended setup.
If you have configured JTA in your app, I think that disabling it for JMS access is actually quite unusual.
Comment From: wilkinsona
If we take that route, should we re-evaluate #7394 and #7463?