New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for multiple ContainerCustomizer (spring-amqp) #32617
Comments
We've taken our lead from Spring AMQP which supports a single customizer. We could make your workaround part of Boot but that feels like we'd be going in a direction that Spring AMQP has chosen not to support. In short, I think you should raise this with with Spring AMQP. If the team decides that I'm going to close this issue for now as there's nothing that we can do or would want to do in Boot at this time. If a change is made in Spring AMQP we can re-open and update Boot accordingly. /cc @garyrussell |
A simple solution, which retains the separation of concerns would be to implement a If you would like to implement that, and contribute it to spring-amqp, no Boot changes would be required (as long as you don't declare the delegates as beans). |
@garyrussell this kind of delegate/adapter code is my current solution and I was thinking of moving such logic too spring-boot auto-config. It is not clear too me why the composite/adapter code must reside inside spring-amqp?! Why an Adapter class in spring-amqp and not just a list? @garyrussell and @wilkinsona please make a final decision where to put the new code: either spring-boot or spring-amqp (or do both projects require changes?!) I can then create a pull request. Thank you for your time. |
If the composite customizer resides in spring-amqp, it would be available to users that don't use Spring Boot (as well as Boot users). It makes more sense too, because the interface resides there. It would be a simple addition there (plus some small doc updates) and would not require any boot changes - the Boot team are extremely busy right now. |
fyi: the PR for introducing As soon as spring-boot (2.7.x or 3.0.x) references this new release, I will make a PR for spring-boot. |
Why do you need changes to Boot? Just add the composite customizer as a single bean, don't declare the delegates as beans, or mark the composite as |
ah... very nice idea @garyrussell. the thing is, that your solution is a little bit different compared to the configuration of other customizers in spring-boot, e.g. the
I would love to have "one" way to handle all kinds of customizers and I thought, that spring boot autoconfig is the abstraction to facilate the customizer handling (see my 1st comment of this issue). |
I understand it is a different technique. My personal preference is the composite approach; it is simpler and you are in total control of the sequence in which customizers are called. With the Boot approach you have to implement |
Hello community,
I have a feature request.
Background: I have splitted up my
ContainerCustomizer
logic into multiple parts in order to increase focus (one takes care of timeouts, another one takes care of consumer concurency and so on).Currently, SpringBoots auto-configuration for
ContainerCustomizer
allows only one instance at a time.My currenct work around is to provide one
ContainerCustomizier
as an adapter which delegates the work to eachContainerCustomizier
, like this:I know that I could encapsulate all me customization into one
ContainerCustomizer
but,WebClientCustomizer
Please let me know if my feature request to add logic that can handle multiple ContainerCustomizer` is feasable/useful.
If so, I could provide a pull request.
The text was updated successfully, but these errors were encountered: