configuration help

[sean mcdaniel]

i work in a very constrained environment where our
CM has mandated that we need to build once with the
ability to deploy the ear file to any of our environments
(4 in total). to address this mandate we have come
up with a solution that includes a specialized property
file format and a system (-D) level property that
specifies the runtime env. here's an example that
demonstrates what i'm talking about. this is the
properties file format where we use a special '[ ... ]' in
front of the property.

property file:
[test] jdbc.password=lasdj(*==
[prod] jdbc.password=jfdsa(*==
[all] app.name=appName
.... etc

and we set a system property to map to the correct
environment when we start the server:
java -Denv=test

so based on this simple naming convention we can
resolve the correct property value for a given
environment but this requires some special handling
and this is where i'm having difficulty. i have a
special env aware propertyreader that i need to use
as the source for the properties.

long story short, i want to be able to use the
placeholder mechanism but i need the properties to
be fetched using my special propertyreader. i would
appreciate any recommendations that would help me
to solve this problem.

[Dave Syer]

I think the only solution is to write your own BeanFactoryPostProcessor. The Spring property placeholders work really well, but they aren't designed to be extensible in this way. Fortunately they are pretty simple. You probably need to copy and adapt the code from the visitor (private inner class) in PropertyPlaceholderConfigurer.

If you have a large amount of data in your properties file, you might want to consider Apache commons logging as an alternative (once you are writing your own placeholder configurer, you are not tied to properties files). With commons logging you can have a hierarchy of entries, like in your example, with overrides and defaults built in. On the other hand, if you have something that already works, why fix it?

[Costin Leau]

Since you are parsing a custom properties file, I think you should extend the class and plug in your own parsing - the properties format is actually changed and you have to adapt the reader to it.

[sean mcdaniel]

Since you are parsing a custom properties file, I think you should extend the class and plug in your own parsing - the properties format is actually changed and you have to adapt the reader to it.

costin,

first off thanks for the response. i'm a bit new to custom config in
spring so could you give me a bit more detail here? the reader/parser
is already written. so which class should i extend and which method(s)
will require overriding? i was thinking that maybe i should simply merge
the properties from my reader into the context's properties. another
option is i could dump all the properties to the System properties.
not sure which is the best approach.

[Costin Leau]

Let me clarify - I was suggesting what you already said - merging the properties read by your reader into the Spring classes (i.e. PropertyPlaceholderConfigurer). I haven't looked closed at it (as David) but it should be possible to add the already parsed properties.
If this doesn't work, one thing you could do (even from the configuration file) is to inject a Properties object instead of a property location - this way you do all the parsing and the configurer does only the replacement.

[sean mcdaniel]

ok found a solution that works ok. i'm still reading in the
property file as a location but all i needed to do was
to override the resolvePlaceholder method to use the
convention that i specified above. something like
this:

String propVal =
super.resolvePlaceholder( placeholder, props, systemPropertiesMode );
if ( null == propVal ) {
String env = resolveSystemProperty( "env" );
propVal = props.getProperty( "[" + env + "]" + placeholder );
}