Add support for non-component @PropertySource discovered by @EnableConfigurationProperties

[bdshadow]

According to the documentation @PropertySource works on @Configuration classes. However, it would be very beneficial, if it would also work when it's not a @Configuration (not a @Component in general) and is referenced by @EnableConfigurationProperties.

For example, this doesn't work:

@Configuration
@EnableConfigurationProperties(AdditionalProperties.class)
public class Config {   
}

//@Component
@ConfigurationProperties
@PropertySource(value = "classpath:my.properties")
public class AdditionalProperties {

    private String name = "";

    //getter and setter
}

But as soon as you comment the @EnableConfigurationProperties in the Config and uncomment the @Component in the second class, it starts working and loads properties correctly from my.properties file.

You can find the full code here to try it out: https://github.com/bdshadow/SpringCustomProperties

I know that AdditionalProperties is registered as a bean by EnableConfigurationPropertiesRegistrar. And it is a bean when explicitly annotated by @Component. Then why is there a difference in behavior regarding the @PropertySource?

[philwebb]

Thanks for the suggestion, but I'm not sure that we should support this. @PropertySource is really part of the application configuration where as @ConfigurationProperties is really about binding to the Environment, rather than setting it up. I also suspect we'd run into implementation problems if we try to support this with constructor binding.

Let's see what the rest of the team think, but my vote would be to close this issue.

[bdshadow]

@philwebb thank you for your reply. I understand, that it might not be implemented. Maybe in this case it would be useful to mention it in the docs more explicitly. Or maybe I'm missing it.

Just spent lots of time today 😃, following the docs for @EnableConfigurationProperties and then for @PropertySource. It was not obvious that it doesn't work together, at least for me

[snicoll]

following the docs for @EnableConfigurationProperties and then for @propertysource. It was not obvious that it doesn't work together, at least for me

As Phil already explained, these are two completely different things. The former is binding from the environment and the latter is mutating the environment (adding a property source with whatever the annotation defines). It's really hard for us to document all the possible cases that users might consider for the application arrangement. Especially when the features are cross projects.

If you want your setup to be reproducible and solid, the environment should be prepared as soon as possible. I understand the framework feature that got created before Spring Boot was a thing is tempting (“it's just an annotation”), but it has some drawbacks, see Point 2 of this section of the reference guide.

My vote is to close this issue as well.

[philwebb]

Thanks @snicoll. I'm going to close this one.

[wilkinsona]

I agree with this being closed. Just for future reference, it reminded me of #5129 and I think it would be likely to cause similar confusion, particularly in terms of the scope of the new property source and exactly when it is applied. IMO, #24688 or something similar will be the right way to address the sort of need raised in this issue.