You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, CLI detection of Rabbit vs. JMS requires a special annotation for each, due to name collisions of SimpleMessageLIstenerContainer.
If we see RabbitTemplate for a producer, we can flag it as Spring Rabbit.
If we see DefaultMessageListenerContainer, it's Spring JMS.
If we see SimpleMessageListenerContainer and it has a method starting with "setDestination*", it's also Spring JMS.
If it's SimpleMessageListenerContainer and it has a "setQueue*" method name, it's Spring Rabbit.
These last two clues will require another AstUtils utility method designed to peek at method names for a given class node so we can deduce whether it's Spring JMS or Spring Rabbit.
With those changes, we can deprecate the @EnableRabbitMessaging and @EnableJmsMessaging annotations and eventually remove them.
The text was updated successfully, but these errors were encountered:
This is now handled via @EnableJms and @EnableRabbit that provides an explicit support of bringing the right dependencies and imports. I don't think there is anything more automated we could do at this point.
Is there a use case where adding that single annotation is an issue?
Right now, CLI detection of Rabbit vs. JMS requires a special annotation for each, due to name collisions of SimpleMessageLIstenerContainer.
These last two clues will require another AstUtils utility method designed to peek at method names for a given class node so we can deduce whether it's Spring JMS or Spring Rabbit.
With those changes, we can deprecate the @EnableRabbitMessaging and @EnableJmsMessaging annotations and eventually remove them.
The text was updated successfully, but these errors were encountered: