Skip to content
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

context:property-placeholder should accept comma-separated list as placeholder value for its location attribute [SPR-10502] #15135

Closed
spring-projects-issues opened this issue Apr 30, 2013 · 5 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Apr 30, 2013

Marton Dinnyes opened SPR-10502 and commented

I can't entirely configure property-placeholder from system property because I can't give comma-separated list of resources.

I'm trying to do like:
<context:property-placeholder location="${config-location}" />

I use system property to configure this. It works if I give one location only, like "classpath:main.properties", but it does not if I'm trying this: "classpath:main1.properties,classpath:main2.properties".

If I use this latter exact value directly in xml configuration it works fine. I guess it resolves comma-separation earlier than placeholders. It should be the other way around.


Affects: 3.2.1

1 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 7, 2016

Sergei Ustimenko commented

PR opened at #1156 and waiting for review

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 2, 2016

Juergen Hoeller commented

I'm rolling this into 4.3.4 still but with a different implementation: Since AbstractPropertyLoadingBeanDefinitionParser does the splitting of the location attribute before passing it on to the factory as a property value, it should also be responsible for resolving placeholders ahead of that step. Our ComponentScanBeanDefinitionParser is applying such behavior to its base-package attribute already, so we're aligning with this in AbstractPropertyLoadingBeanDefinitionParser now.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 2, 2016

Sergei Ustimenko commented

Juergen Hoeller
Please check out my original changes, which have exactly the same behavior, as you described.
I will update my PR with these changes, so you can easily get them.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 2, 2016

Sergei Ustimenko commented

Juergen Hoeller PR have been updated with original changes, please take a look at them

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Nov 3, 2016

Juergen Hoeller commented

I had a more extensive commit prepared along the lines of my comment already, which I've pushed to master now and will backport to 4.3.x right afterwards. Not only does it implement the early placeholder resolution in the spot I mentioned above, it also uses the current Environment abstraction to resolve placeholders (which falls back to system properties but can use any property sources in the current Environment setup), and it revises our <util:properties location="..."> support the same way.

Thanks for your efforts, in any case!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants