-
Notifications
You must be signed in to change notification settings - Fork 40.8k
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 Pulsar container factory customizers #42182
Add Pulsar container factory customizers #42182
Conversation
This commit adds the ability for users to customize the auto-configured Spring for Apache Pulsar message container factories. Each container factory holds a set of container properties that is a common target for users to configure. Allowing the customization of these properties prevents a rapid increase of configuration properties.
Thanks for the PR. Rather than 3 customizer interfaces, can you please look if we could replace that with a generic? See |
@snicoll thanks for pointing out the |
...-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/messaging/pulsar.adoc
Show resolved
Hide resolved
...-boot-project/spring-boot-docs/src/docs/antora/modules/reference/pages/messaging/pulsar.adoc
Show resolved
Hide resolved
This commit adds the ability for users to customize the auto-configured Spring for Apache Pulsar message container factories. Each container factory holds a set of container properties that is a common target for users to configure. Allowing the customization of these properties prevents a rapid increase of configuration properties. See gh-42182
This commit adds the ability for users to customize the auto-configured Spring for Apache Pulsar message container factories. Each container factory holds a set of container properties that is a common target for users to configure. Allowing the customization of these properties prevents a rapid increase of configuration properties for secondary priority properties.
Note
I originally submitted a PR to add config props for the startup failure options and timeout. However, in most cases, that alone is not sufficient and users will want to create their own retry template custom to their environment/scenario. This lead for the need to either allow users to configure in retry templates for each container (which would require
@Qualifer
and got messy quick. By allowing customization of the container factory we allow ourselves to get out of the "I need to add another config property" business for properties that are not primary in nature. Configuring the startup failure policy is probably not a primary operation. If we agree w/ this then the other PR can be closed in favor of this proposal.