KafkaBinderConfigurationProperties is still not showing up in the generated JSON for config props

[rod2j]

Issue spring-cloud-stream-binder-kafka#750, despite having been closed, is still present in version 4.0.1 of Spring Cloud Stream.

KafkaBinderConfigurationProperties still has a single parameterized constructor, so "ConstructorBinding" is still automatically applied,
resulting in a spring-configuration-metadata.json missing all the properties of the KafkaBinderConfigurationProperties class, except those of the KafkaProperties class passed as an argument of the constructor.

[sobychacko]

@rod2j I created this issue in Spring Boot to address the root cause of this behavior: spring-projects/spring-boot#34031. Thanks for reporting this issue.

[sobychacko]

@rod2j This issue is now fixed through the above-referenced commit. Please try it with version 4.0.2-SNAPSHOT of the binder and see if the issue is resolved.

[philwebb]

@sobychacko You might want to try removing @ConfigurationProperties from KafkaBinderConfigurationProperties and adding it to the @Bean method instead:

@ConfigurationProperties
@Bean
KafkaBinderConfigurationProperties configurationProperties(
		KafkaProperties kafkaProperties) {
	return new KafkaBinderConfigurationProperties(kafkaProperties);
}

I think this will give the annotation processor enough information to know that constructor binding cannot be used.

[sobychacko]

@philwebb We also noticed that adding the @Autowired to the constructor of KafkaBinderConfigurationProperties solved the problem of running the app as a native one in certain situations. Basically, none of the JavaBean bindings were working without the @Autowired on the constructor, possibly due to not generating the proper reflection hints. However, adding the @Autowired fixed that issue. Do you think if we add the @ConfigurationProperties as you suggested on the bean method, will it behave correctly for the native apps as well?

[philwebb]

@sobychacko I think so, but I've not confirmed that for sure. It's certainly a bug if it doesn't.

[sobychacko]

Re-opening this issue until we verify the suggestion made by @philwebb ^^.

[sobychacko]

@philwebb Moving @ConfigurationProperties from KafkaBinderConfigurationProperties and adding it as part of the @Bean method works for the proper generation of the configuration metadata. However, that native issue I mentioned above still needs the @autowired on the constructor. Without that, some hints for the JavaBean style properties in KafkaBinderConfigurationProperties are not generated. Do you see any harm in leaving the @autowired on the constructor but moving the @ConfigurationProperties to the @Bean method? Thanks!

[sobychacko]

Since the @autowired approach worked for both situations, I wonder whether we can stick with that strategy instead of moving the @ConfigurationProperties to @Bean? What is the downside of using the @autowired approach on the constructor?

[philwebb]

It should be fine to leave it, it just looks a bit odd because it's not actually being used for autowiring.

[sobychacko]

Re-opened again until we have a resolution for the native issue discussed above.

[sobychacko]

Spring Boot fixed the issues, due to why we needed to add @Autowired on the KafkaBinderConfigurationProperties constructor. We removed the @Autowired and confirmed that the native applications work without it. See the following Boot issues for details.
spring-projects/spring-boot#34507
spring-projects/spring-boot#35564