Working on a Kotlin sample where we call DefaultJmsListenerContainerFactory.setTransactionManager(null) and I see an error. I think it might be because the parameter on the method isn't marked as @Nullable even though the field is.
Comment From: snicoll
@philwebb thanks for the report. I am not sure we should change that. I think that the intention is that you might configure an aspect of the DefaultMessageListenerContainer that this factory configures. If you do, the intention is that you actually provide a valid component. My take is that we should rather not call the method if we don't have a PlatformTransactionManager.
@jhoeller added the nullability on this one so I'll defer to him.
Comment From: jhoeller
I agree with @snicoll here: The design of those dedicated factory classes - with only setters, no getters - suggests that each setter method should only be called with a non-null argument, or simply skipped. If we decide to change this design, we'll have to redeclare all applicable setter methods with nullable arguments there. However, I'd rather suggest the existing design.
A side note: We have nullable setter arguments in other places but mostly just when getter methods exist that might have to return null in case nothing has been set (yet). This is required for consistency since otherwise tools (and also the Kotlin compiler) cannot infer property-level nullability for such a setter/getter pair.
Comment From: philwebb
It's certainly an edge case. For the documentation in question we're trying to reconfigure a DefaultJmsListenerContainerFactoryConfigurer that has it's setTransactionManager called by some other code. I'll open a Boot issue to see if we can offer an alternative configure method that doesn't set the transaction manager.