Skip to content

@Enable-style annotation is desired for automatic registration of PropertySourcesPlaceholderConfigurer [SPR-9904] #14537

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Oct 22, 2012 · 9 comments
Assignees
Labels
has: votes-jira Issues migrated from JIRA with more than 10 votes at the time of import in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Oct 22, 2012

Andrey Rubtsov opened SPR-9904 and commented

This issue is a continuation of #13183. Long story short, Environment is advertised to be used in new Spring projects.
However, in those cases when using PSPC is still wanted instead of declaring it as a @Bean it would be nice to have @Enable-style annotation instead for it.
The main argument so far is probably that PSPC @Bean looks slightly unnatural among app specific beans because it is related to Spring internals rather than carrying application bean semantics.


Issue Links:

16 votes, 26 watchers

@spring-projects-issues
Copy link
Collaborator Author

Chris Beams commented

Thanks, Andrii.

@spring-projects-issues
Copy link
Collaborator Author

B. K. Oxley (binkley) commented

The main argument for me is not aesthetic, it is practical. To move from XML to Java configuration means rewriting beans using @Value annotations.

@spring-projects-issues
Copy link
Collaborator Author

Wojciech Krak commented

It's waste of time, that this doesn't work automatically right now. I lost couple of hours, why after move from xml to javaconfig my @Value(s) stop working. I'm sure that I'm not the only one and maybe in a few months I won't be remember that, so I'll lost my time once more.

@spring-projects-issues
Copy link
Collaborator Author

Mark Pollack commented

I agree that we are not following the 'principle of least surprise' here. I also don't agree with argument in the previous JIRA not to use @Value wrt to verbosity. Sure, for JDBC configuration I might have to have 4 @Values, but from a quick look at the @Configuration class I can see what values are being injected and in a style that is consistent with pretty much how all other properties are going to be injected that don't involve 4 @Values for one logical entity. Injecting Environment and then pulling values out of that feels more like a 'service locator' approach, and it is still 4 lines of code. Boot's @EnableAutoConfiguration is effectively achieving the same thing as requested in this issue...

@spring-projects-issues
Copy link
Collaborator Author

Dave Syer commented

I agree 100% that injecting an Environment and using its API is the wrong thing to do for most people. It's hard to see why @EnablePropertySources would be necessary though since it would only add a single @Bean that you can do in one line anyway (and you have to do it in XML anyway). Please use @EnableAutoConfiguration.

@spring-projects-issues
Copy link
Collaborator Author

Christopher C. Merris commented

Adding my vote here. I also wasted an hour and a half expecting @PropertySource to "just work".

Also +1 on env.getProperty feeling like service locator.

@spring-projects-issues
Copy link
Collaborator Author

Tomáš Hanus commented

I have to agree with reporter. This behaviour is what I am expecting when developing new app under Spring Boot. On the other hand we rather use environment approach (with spring boot) that support external configuration over many resources (chain of configuration resource) and one of them is DB. It is more flexible, but sure, it is about knowledge. Default behaviour should be as simple as possible.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Mar 28, 2017

Sam Brannen commented

Juergen Hoeller, I'm thinking this has effectively been superseded by #18712.

Thoughts?

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Mar 31, 2017

Juergen Hoeller commented

Indeed, with the standard placeholder resolution brought by #18712, the main use cases are covered here. Only really the replacement of placeholders in external bean definition values (like XML property definitions) requires an explicit Property(Sources)PlaceholderConfigurer now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has: votes-jira Issues migrated from JIRA with more than 10 votes at the time of import in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants