Skip to content

Make use of configurer pattern consistent #50166

@snicoll

Description

@snicoll

Spring Boot has introduced the concept of configurer when users would like to create custom instances of a given type whilst retaining the behavior of auto-configuration. They can decide to tune settings before and after calling a configure method. They also can pass a sub-class of the type to configure (if possible) to get exactly what the auto-configuration produced, but with a type that may provide customization of protected methods.

I believe #5138 is the issue that started this pattern.

Looking at the codebase, we have used this in other parts but some usage are now inconsistent. Here's a summary of where we are:

  • JMS has kept the original idea with a configure method that takes the factory and a ConnectionFactory. The default instance is created by injecting the configurer and calling configure on it.
  • Kafka is problematic as a number of customizers are applied manually which means a configure won't do the same thing as the auto-configuration. Users are reporting, for instance, that they lose observability when using this pattern.
  • Rabbit:
  • Redis is new and is following the pattern for JMS
  • RestClientBuilderConfigurer is sane, with the default builder created by a one-liner from the configurer.
  • RestTemplateBuilderConfigurer is sane, with the default builder created by a one-liner from the configurer.

Rabbit and Kafka needs some work to re-align what we intended with the configurer pattern.

Metadata

Metadata

Assignees

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions