This is a draft only meant to demonstrate a possible solution for https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit/issues/187
Simply splits the RabbitAutoConfiguration into separate config classes so that the SCSRB can depend on the non-auto-config rather than the auto-config.
Comment From: wilkinsona
Thanks for the proposal, @bono007, but I'm afraid that I don't think this is the right way to go.
Other than their classes (used for ordering and exclusion), we don't consider auto-configuration classes to be public API. For this reason, while …AutoConfiguration classes are public we try to minimise the visibility of their methods and any classes that they @Import. Making RabbitConfiguration and RabbitMessagingTempleConfiguration is at odds with this approach so we'd prefer to find an alternative solution.
Thanks for the proposal and sorry for any wasted effort here. Let's continue the discussion on spring-cloud/spring-cloud-stream-binder-rabbit#187. If you have any other ideas, please feel free to describe them there and we can comment on their practicality from a Spring Boot perspective at least.
Comment From: onobc
Thanks for the proposal and sorry for any wasted effort here
Not a problem @wilkinsona . This is why we call these "code proposals" 😺 . The effort was minimal and I learned a little something along the way.
The struggle I had was between creating a Spring Cloud Stream Rabbit Binder (SCSRB) Rabbit config and re-using the Spring Boot (SB) Rabbit config. Some pros/cons (mostly converse of one another):
Re-use the Spring Boot Rabbit config classes
(+) DRY principle
(+) parity sync - the SCSRB will use the same Rabbit config code as SB
(-) violates the auto-config-is-private-api principle
(-) tightly coupled, another integration point to SB
Create a Spring Cloud Stream Rabbit Binder (SCSRB) Rabbit config
(-) duplicates the SB Rabbit config code
(-) parity drift - the SCSRB version will get out of sync w/ SB version quickly
(+) does not violate the auto-config-is-private-api principle
(+) less coupling
I think the false assumption I was making is that the SCSRB version needs to have all the config knobs the SB version has. If this is not the case then the argument above for "parity / lockstep" can be thrown out the window. Identifying the minimal set of config options needed by SCSRB would be a good start.
As you suggested, I will comment on spring-cloud/spring-cloud-stream-binder-rabbit#187 when I have other ideas. Also, the fact that the binder service config looks like it will be largely re-worked, this Spring Boot auto-config aspect of it may not exist once that happens.
Thank you for the quick turnaround and feedback.