|
[
Permlink
| « Hide
]
Chris Lee added a comment - 10/Apr/06 03:28 PM
Reference implements - RuntimeEnvironmentPropertiesConfigurer
Chris has a good point here. I resolved the very same use case he describes having MethodInvokingFactoryBean call System.getProperty and using the returned value to set the location property of PropertyPlaceholderConfigurer.
His solution is obviously much cleaner and at the same time easy to implement and doesn't add too much complexity. I hope for the adoption of his proposal. Ciao, Fabio. I suggest extending the concept even farther:
- read the configuration name (ie, dev, staging, production) from a text file. - read the configuration value from a URL. - read the configuration value from a database (ie, provide a datasource and SQL statement) I'll be posting a v2 with a pluggable RuntimeEnvironmentKeyResolver; the default implementation will be equivalent to what is there now. This will allow users to provide their own implementation(s), resolving the current environment in an appropriate manner.
Chris. Version 2 is attached; this adds an (optional) RuntimeEnvironmentKeyResolver interface, allowing for custom implementations that determine the runtime environment in an appropriate manner. The default implementation still uses a system property.
The following thread goes into a bit more detail about why this change is important: http://forum.springframework.org/showthread.php?t=24066
Added an environment aware version of ClassPathXmlApplicationContext and another RuntimeEnvironmentKeyResolver implementation.
RuntimeEnvironmentPropertiesConfigurator line 117, empty while loop due to semi-colon
The above is the 1.4 backport only. Please disregard.
Another approach is to use an EagerPropertyPlaceholderConfigurer to load the properties file specified by a system property.
Please see the link of a related issue: [link]http://opensource.atlassian.com/projects/spring/browse/SPR-1076[/link] EagerPropertyPlaceholderConfigurer is a orthogonal approach to resolving properties; would be nice to merge the two concepts, so that we have the ability to eagerly load properties and specify (with validation) which environment to load properties for.
Is this a related issue: http://opensource.atlassian.com/projects/spring/browse/SPR-2335 ?
Keep in mind that the problem stated here (and the proposed solution) covers more than just property differences between environments - specifically it also covers differences in bean wirings between environments (something that property placeholders do not support by themselves).
This is a reasonably common use case; eg. * developer sandbox environments have mock versions of DAOs / web service clients / what-have-you configured but other environments are configured with the real thing * integration test environment has a series of "validation shims" (akin to JDK 1.4+ asserts, only more sophisticated) configured but other environments don't * performance test environment has a series of "timing shims" configured but other environments don't etc. etc. Issue http://opensource.atlassian.com/projects/spring/browse/SPR-2335 does not address the same use case.For details please read [url]http://opensource.atlassian.com/projects/spring/browse/SPR-2335#action_19719[/url]
As an alternative, what about specifying all the properties in a single file. I like this from a maintainer's perspective. All properties are in one file. You could have default properties and override them by environment, only if necessary. The properties file would look like:
# this is the default value for all environments my.prop=defaultValue # but in the production environment, it is different [production].my.prop=productionValue # here's another property with no default [development].my.prop2=someDevelopmentValue [test].my.prop2=someTestValue [production].my.prop2=someProductionValue The beandef would specify only the property name minus the environment and the Configurator would resolve appropriately: "${my.prop}" Makes perfect sense in the case where the set of properties isn't too large, although you can still get the same defaulting behaviour using Chris' original implementation (although using multiple files, rather than a single file as you suggest).
If you implement this, would you mind using the same environment key resolver infrastructure? That just makes it easier for users of this functionality to mix and match the various approaches without having to change the way their environments are identified. I think this should be implemented in the core. Juergen, where you at on this one buddy :)
I have found at least 12-15 articles about this very issue, and Spring needs an official implementation to address it IMO. This is a great start guys! Anyways, support for multiple properties files with a configurable convention would be nice too. This way you could have something like: jdbc.development.properties jdbc.staging.properties jdbc.production.properties Sometimes this is needed due to framework constraints while trying to satisfy the DRY principle. This is definitely required.
Here's my take on the subject from yonks ago: http://forum.springframework.org/showthread.php?t=46504 Why is linking issues disabled?
This issue is related to: http://jira.springframework.org/browse/SPR-1358 http://jira.springframework.org/browse/SPR-1076 http://jira.springframework.org/browse/SPR-1332 |
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Minor
Extend PropertyPlaceholderConfigurer to choose property file based on runtime environment
