Skip to content

@Value("${someProperty}") should work without having to specify a PropertySourcesPlaceholderConfigurer bean. [SPR-11773] #16395

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 May 9, 2014 · 4 comments
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented May 9, 2014

Adam Berlin opened SPR-11773 and commented

This came up while discussing the injection of YAML configuration using @Value in Spring Boot. (spring-projects/spring-boot#821) The configuration file is loaded by spring-boot, but it is not accessible to @Value until:

@Bean
public PropertySourcesPlaceholderConfigurer configurer() {
    return new PropertySourcesPlaceholderConfigurer();
}

This seems like unnecessary busy-work when setting up my application. Who knows what a PropertySourcesPlaceholderConfigurer is? That should be something the framework sets up for me automatically.


Issue Links:

2 votes, 4 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented May 9, 2014

Juergen Hoeller commented

This is related to #14537 in the sense of nicer enabling of property placeholder substitution. #14537 suggest a dedicated @EnableX annotation for that purpose, along the lines of our existing context:property-placeholder element, which is probably a good compromise for your purposes as well. At the very least, it doesn't require knowledge of the PropertySourcesPlaceholderConfigurer class name; instead, it can be found through auto-completion of @Enable*.

Simply enabling a PropertySourcesPlaceholderConfigurer by default would unfortunately make it hard to set up custom resolution strategies since those have to remove/override the default placeholder configurer in some way. This is not a single strategy but rather an interacting chain of post-processors, so it's hard to replace default processors there.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Adam Berlin commented

Is this maybe something that Spring Boot should take an opinion on, and it should create the @Bean automatically?

@spring-projects-issues
Copy link
Collaborator Author

Stéphane Nicoll commented

Adam, that's a question to ask on the boot tracker. I can't move that issue there unfortunately.

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: enhancement A general enhancement label Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants