Should we be using JmsOperations instead of JmsTemplate? (And similarly JmsMessagingOperations vs JmsMessagingTemplate)

Question

My team and I were having a deep dive in overviewing one component, and we were discussing about a delegate implementation of a JmsTemplate.

Diving into the code, and I found that in most scenarios, based on SOLID principles, we should expect in our components the JmsOperations interface, not the JmsTemplate that is the implementation.

Looking at Spring Documentation on JmsTemplate I see:

Instances of the JmsTemplate class are thread-safe, once configured. This is important, because it means that you can configure a single instance of a JmsTemplate and then safely inject this shared reference into multiple collaborators. To be clear, the JmsTemplate is stateful, in that it maintains a reference to a ConnectionFactory, but this state is not conversational state.

The 'once configured' to me means setting properties like pubSubDomain and default destination that shouldn't be changed once set but the old JavaBean structure of the JmsTemplate allows changing. (eg: shared JmsTemplate, one thread sets pubSubDomain to send a message to a topic, in the same time another thread uses it to publish to a queue)

Am I wrong? Is inside Spring Framework privileged JmsTemplate or JmsOperations as injected beans. Are my worries unfounded? I'd like some shared experience, and maybe some words from the Spring team

Answer 1

You are correct, you must not mutate properties of a shared template at runtime; you need two templates, one for pub/sub, one for queues.

Whether you inject it via the interface or concrete class makes no difference in this case.

It's generally preferable to reference it via the interface because it makes it easier to inject a mock implementation in tests, or otherwise swap in some other implementation if needed.