Adds a new configuration property spring.kafka.admin.modify-topic-configs to facilitate enabling of this recently added functionality
Comment From: wilkinsona
Thanks for the proposal. We can consider this for 3.0.x but it's too late now for 2.7.x, particular given that it's only a few lines of code to define your own KafkaAdmin bean:
public KafkaAdmin kafkaAdmin(KafkaProperties properties) {
KafkaAdmin kafkaAdmin = new KafkaAdmin(properties.buildAdminProperties());
kafkaAdmin.setFatalIfBrokerNotAvailable(properties.getAdmin().isFailFast());
kafkaAdmin.setModifyTopicConfigs(true);
return kafkaAdmin;
}
@garyrussell do you think it makes sense to surface a configuration property for this setting?
Comment From: m-kay
@wilkinsona The reason I would have liked it as configuration property is to make it easily configurable in a k8s environment.
Comment From: wilkinsona
@m-kay Until Boot has a property, you can externalise it using your own property. You could even name that property spring.kafka.admin.modify-topic-configs if you were prepared to deal with a potential clash in the future.
Comment From: m-kay
Yes sure I can do that. I just thought I could also help others with this small change here :wink: Besides that I like to use spring boots auto configuration wherever possible, instead of creating the beans in my own config, to benefit from new configurations added in future releases.
Comment From: garyrussell
Yes, it makes sense to add it. Perhaps a simpler work around (without having to add your own KafkaAdmin bean) is to set the property in one of the NewTopic bean definitions.
@Bean
public NewTopic topic(KafkaAdmin admin) {
admin.setModifyTopicConfigs(true);
return TopicBuilder.name("topic1")
.partitions(1)
.replicas(1)
.config("retention.ms", "60000")
.build();
}
Comment From: wilkinsona
Thanks, Gary. We'll add the property in 3.0.
FWIW, that mutation feels a little risky to me as its ordering with respect to other usages of KafkaAdmin is undefined. It may be fine given how Spring Kafka uses the KafkaAdmin bean but, generally speaking, I wouldn't recommend a @Bean method mutating another bean.
Comment From: garyrussell
I agree, in general, but in this case it's safe because KafkaAdmin is a SmartInitializingSingleton so it doesn't do any work until all the beans have been instantiated.
Comment From: snicoll
@m-kay thank you for making your first contribution to Spring Boot.