Configuration Processor @Bean Duplicate Prefix Definition APT Error

[nwoike]

When using the spring-boot-configuration-processor and leveraging the same @ConfigurationProperties prefix on an @Bean I am seeing an APT error in Eclipse in 1.4.0.RELEASE. While I agree that this error should be generated when using a duplicate prefix on an @Component class definition, I think this restriction should be relaxed on @Bean definitions.

I am referencing the External Config 3rd Party Configuration section in the reference guide.

Basic example of the issue

@Bean
@ConfigurationProperties("spring.datasource.tomcat")
public DataSource readDataSource() {
        return DataSourceBuilder.create()
            .url(properties.getReadUrl())
            .username(properties.getUsername())
            .password(properties.getPassword())
            .build();
}

@Bean
@ConfigurationProperties("spring.datasource.tomcat")
public DataSource readWriteDataSource() {
        return DataSourceBuilder.create()
            .url(properties.getReadUrl())
            .username(properties.getUsername())
            .password(properties.getPassword())
            .build();
}

Duplicate `@ConfigurationProperties` definition for prefix 'spring.datasource.tomcat'.

[snicoll]

I don't think it should. If we relax it as you ask us to do, it will generate the meta-data twice. Or are you implying that if the type and the prefix are the same we should "ignore" the second occurrence? I am not sure I want to do that.

Besides, this code of yours is a bit weird. You basically have two data sources that you configure from the same prefix. I'd rather have some kind of explicit pojo (a builder or something) to make it more clear.

[nwoike]

The documentation describes this use case for "binding properties to third-party components that are outside of your control." So, for this usage, should metadata be generated when used on these types of @Bean definitions at all?

I am not advocating duplicating metadata generation. But I have several other usages of @ConfigurationProperties on my own classes that I do want to use the configuration processor on.

[nwoike]

It may be a poor example, I just wanted to illustrate a use of dynamic property binding as used internally in Spring Boot's own Auto-configuration. As far as I know there is no @ConfigurationProperties bean or builder to configure DataSource connection pool properties.

[snicoll]

should metadata be generated when used on these types of @bean definitions at all?

Of course it should, you are writing "spring.datasource.tomcat.xyz" in your own config aren't you? The whole point of this is that you should get content assistance when you do. Binding two different bean definitions to the same prefix is a smell in my book. You could perfectly have "spring.datasource.tomcat.url" in your config and you would override the URL to use for both data sources. I am sure that's not what you want.

I have several other usages of @ConfigurationProperties on my own classes that I do want to use the configuration processor on.

Don't add the annotation processor to your build then. I'd argue that if you don't want the meta-data, something else is wrong. Ultimately it means you want to bind your bean to a certain prefix but you don't want content assistance for it.

as used internally in Spring Boot's own Auto-configuration.

Where? If you look how we're using it, we target different prefix. And for the datasource case if you look closer you'll see that the type of the DataSource is different as well (to generate the proper metadata per prefix).

Can we take a step back and look at what you're trying to solve and why you have two beans with the exact same signature?

[bclozel]

@nwoike Sorry for asking this, but I still don't get the use case for this.

Are you trying to conditionally register beans depending on Profiles to avoid using application-read.properties and application-write.propreties? The example you gave is not clear and it's mixing many concerns.

Could you describe this use case in another way maybe?
For example, what you have to write right now to achieve what you want and how that feature could help you make it more elegant/easier to write and maintain/etc.

Thanks