I have a Spring application that uses annotation driven JMS listeners, i.e. I have some classes with methods annotated with @JmsListener. In this annotation, I do not set the attribute subscription.
However, since I want to work with topics (rather than queues) and use durable subsribers, I have configured a JmsListenerContainerFactory and set its property subscriptionDurable to true.
Now I expect all the JmsListeners to be durable and have sensible subscription names.
However, in the JMS admin tool, I see that all the subscriptions have the same name: org.springframework.jms.listener.adapter.MessagingMessageListenerAdapter.
I'd expect the default subscription name to be something like <className>.<methodName> (where "className" is the class that contains the method annotated with @JmsListener), but not always the same. This can even lead to an error where several JmsListeners will overwrite each other's subscriptions.
Comment From: fml2
I've found the reason for this behaviour.
When the subscription attribute is not set, a default one is generated.
In my case (I think, this will always be the case if annotation driven message listeners are used) the listener is of type MessagingMessageListenerAdapter.java. This class does not implement the interface SubscriptionNameProvider hence the method getDefaultSubscriptionName returns the class name of the listener.
The solution could be as follows:
1. The class MessagingMessageListenerAdapter should implement the interface SubscriptionNameProvider.
2. The implementation of the interface's method SubscriptionNameProvider should generate the subscription name based on the field handlerMethod. There, the real class and method responsible for message processing is stored so that the generated name will be meaningful.
It should be decided how exactly the name should be generated. One could just take the class name of the "real" class.
Comment From: sbrannen
- Superseded by #29790
Comment From: fml2
Haha, this is an issue and #29790 is a PR for it :-)
Comment From: sbrannen
Haha, this is an issue and #29790 is a PR for it :-)
Yes, that's correct. We close an issue if a PR supersedes it. Having both open clutters the issue tracker. That's our policy.