In July last year, this commit added interface StreamsBuilderFactoryBeanCustomizer (Boot 2.3, which uses S-K ).

An identical interface has existed in spring-kafka for over 2 years (S-K 2.2, Boot 2.1); it is only used to customize the DEFAULT_STREAMS_BUILDER_BEAN_NAME configured by S-K; it looks like Boot is doing the same, just for that same FB.

Consider deprecating the Boot interface (perhaps making it extend the S-K version during the interim), to avoid confusion.

We will then need some mechanism to not apply the customization in S-K if we are running in a Boot app.; in case the customization is not idempotent.

Comment From: wilkinsona

Boot uses its customiser to configure Micrometer metrics:

https://github.com/spring-projects/spring-boot/blob/b5843cfd4dabba09eb8f341c4ea1a3ecfa38d91b/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/metrics/KafkaMetricsAutoConfiguration.java#L78-L81 In Boot you can have n customisers, and each will be called in order:

https://github.com/spring-projects/spring-boot/blob/b5843cfd4dabba09eb8f341c4ea1a3ecfa38d91b/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/kafka/KafkaStreamsAnnotationDrivenConfiguration.java#L76

Given Spring Kafka's requirement that there's only one org.springframework.kafka.config. StreamsBuilderFactoryBeanCustomizer, I'm not sure we can deprecate Boot's in favour of Spring Kafka's as they have different contracts.

Comment From: garyrussell

Doh - I mis-read the method name; I thought they were the same.

It's still rather unfortunate that we didn't pick up this conflict; confusing for users.

I guess we'll have to just live with it.

Comment From: wilkinsona

Yeah, it is unfortunate.

Is it worth exploring the possibility of changing Spring Kafka so that more than one of its customizer can be defined and they'd then be applied in order? That might allow us to deprecate Boot's. It would still be a little unusual as the customizer pattern is common throughout Boot and this would be the first time that an upstream project has provide a customizer that Boot then uses. Another option might be for Spring Kafka to move to a model that's closer to Spring MVC WebMvcConfigurer.

Comment From: garyrussell

Yes; I'll do that and deprecate the name clash.

Thanks for your input @wilkinsona .

Feel free to close with appropriate label(s); I don't have permissions.