Add support for auto-configuring SimpleMessageListenerContainer

[vpavic]

This commit introduces a new spring.jms.listener.container-type configuration property which can be used to auto-configure JMS listener support backend by SimpleMessageListenerContainer instead of DefaultMessageListenerContainer.

[snicoll]

Thanks for the suggestion but we don't really consider a promotion of SimpleJmsListenerContainer to that level. We invest in DefaultMessageListenerContainer for many years and I'd rather not confuse users by giving them a choice.

What's your use of SimpleJmsListenerContainer and why can't you use DefaultMessageListenerContainer.

[vpavic]

Semantics of SimpleMessageListenerContainer are quite different from polling-based approach that DefaultMessageListenerContainer are a better fit for some use cases. Your comment sounds like use of SimpleMessageListenerContainer is discouraged and I don't see that being the case looking at Message Listener Containers section of the Spring Framework reference docs that says this about SimpleMessageListenerContainer:

This message listener container is the simpler of the two standard flavors. It creates a fixed number of JMS sessions and consumers at startup, registers the listener by using the standard JMS MessageConsumer.setMessageListener() method, and leaves it up the JMS provider to perform listener callbacks. This variant does not allow for dynamic adaption to runtime demands or for participation in externally managed transactions. Compatibility-wise, it stays very close to the spirit of the standalone JMS specification, but is generally not compatible with Jakarta EE’s JMS restrictions.

My specific use case is that I'm using SQS and Amazon SQS Java Messaging Library provided by AWS. This JMS implementation doesn't support transactions, but provides custom acknowledge mode that better fits SQS, and internally has its own prefetching/polling mechanism that aligns usage of SQS API with JMS spec. From my experience SimpleMessageListenerContainer is a better fit here since I don't want another layer of polling (and associated set of threads) and dynamic concurrency.

I'd like to avoid copying boilerplate configuration from project to project and use configuration property based approach to opt into using SimpleMessageListenerContainer while also retaining the ability to configure other message listener aspects using properties.

[snicoll]

Your comment sounds like use of SimpleMessageListenerContainer is discouraged

No, it doesn't sound like that. If it was, the class would be deprecated. I wrote "invest", which means we haven't been touching the simple implementation and recommend folks to use the pooling approach. I think we can move forward but I would make the following changes to make the PR actionable:

• Remove the property that switches from one to another. If you want to use the simple implementation, then it's fair to ask folks to create a dedicated factor (potentially replacing the default if they want to switch everything over it). In particular, I don't like the update to configuration properties where half of the properties are now working with one, but not the other
• Update the documentation to explain the difference between the two implementations and why the Simple implementation would be a good fit. I don't want to offer a new option without a justification. Right now, the change is bringing more confusion to regular users.

We can reconsider based on the above, thanks!