Autodeclaration of rabbit artifacts fails on non default connection when `RabbitListener` is used
Closed this issue · 6 comments
During working with this library me and my team have spotted some strange behaviour. Let me describe the whole flow:
We have introduced multirabbit to support connection to multiple vhosts in an elegant way.
Later on we changed our custom MessageListenerAdapters to RabbitListener annotation usage, to simplify our configuration even more. Then we have noticed that autodeclaration of rabbit artifacts works only on the default connection, not the additional ones as previously.
Our current configuration doesn't use bindings or queuesToDeclare part of RabbitListener. Instead we simply declare our queues, exchanges and bindings in a separate configuration classes as beans.
I think that mentioned problem is caused by enhanceBeansWithReferenceToRabbitAdmin method in ExtendedRabbitListenerAnnotationBeanPostProcessor class.
Whenever we have RabbitListener used in our code this method runs and overrides adminsThatShouldDeclare with the currently processed configuration. After that it's not overriten anymore, as adminToDeclare is already set.
If I understand correctly the main reason to introduce this method was to not duplicate artifacts in each configuration. However to achieve this we should operate only on beans that relates to actually processed annotation, not on all rabbit artifacts beans in a context.
What more, the assumption that only one admin can declare given artifact (method isNotProcessed) also seems to be wrong, as eg. in our scenario, we would like to listen on the same queue in different connections.
My suggestion would be to utilize this postProcessing only for queuesToDeclare and bindings scenarios, to not interact with different types of defining rabbit beans
Hi Bartłomiej, thanks for your input.
Autodeclaration should work in all connections. Maybe I'm not getting your premisses very clearly. Is it possible for you to provide an example repository so I can understand that better?
Hi @bhj6-Juroszek, I was rethinking the issue and understood the point. You are right about the override of adminsThatShouldDeclare. And that behaviour is really known, since Spring does not expose the beans during the creation.
We are in the process of contributing spring-multirabbit to the framework, and that thing was spotted by Gary Russel in this comment spring-projects/spring-amqp#1111 (comment) in the contribution to the framework, which is in progress.
As mentioned, in the contribution to spring-amqp library, it was necessary to change the implementation of the default RabbitListenerAnnotationBeanPostProcessor from Spring, which the library does not do.
I will think about a way to fix this issue as an external library, in spring-multirabbit and get back here.
Hi @bhj666, thank you for the contribution. However, the fix will be available when MultiRabbit provides compatibiltiy with spring-rabbit version 2.3.0, which implements the return of declarables from the BPP. This way, the proper declarables are registered with the specific RabbitAdmin, no matter if the beans are directly registered via @Bean annotation of indirectly via @RabbitListener.
With current version from spring-rabbit, it's not possible to find out exactly which declarables should be assigned with precision.
Issue fixed by injecting the RabbitAdmin previously to the processing of the regular Rabbit's BPP.
Release in versions 2.1.6 & 2.2.2