Managing Properties files

[Deepak Dew]

Request to mod: if this is not the right forum, please move it to appropriate one.

Here is the question:

In my company, we have 10s of web applications using JSPs, Servlets, hibernates, Spring but no EJBs.
All these applications have tons of properties which are in properties fil in war-file/WEB-INF/classes/ dir. It is a big pain to maintain these properties file and wondering what are other guys doing to resolve this issue ? How are you guys doing properties management for applications ?

Thanks

Deepak

[Evan Caballero]

In my company, we also use property files. It's the easyiest way to configure applications.

[Deepak Dew]

Evan Caballero wrote:In my company, we also use property files. It's the easyiest way to configure applications.

Thanks Evan
How do you manage your properties files ? Any tools? Any tricks ?

[Evan Caballero]

What do you mean by "how do you manage" ??

[Deepak Dew]

Evan Caballero wrote:What do you mean by "how do you manage" ??

Right now, all the properties file are in text/properties file and we need some kind of token replacing tools to populate these properties files.
We are thinking about how to have a better management and administration of these properties files.
Thanks

[Evan Caballero]

if your application is packaged differently for different environments (dev, prod, etc ...), you should try to use Maven (a packaging tool like ant), and use one profile by environment, with the related property files for each profile.

[Deepak Dew]

Evan Caballero wrote:if your application is packaged differently for different environments (dev, prod, etc ...), you should try to use Maven (a packaging tool like ant), and use one profile by environment, with the related property files for each profile.

thanks this is what we have ( multiple envs ) and this is what we are doing now.

[Evan Caballero]

I don't see a better solution

I remember in my previous company, we used an excel worksheet with the properties, and one tab per environment. To generate each file, there was an excel Macro to do the job.

[Deepak Dew]

Evan Caballero wrote:I don't see a better solution

I remember in my previous company, we used an excel worksheet with the properties, and one tab per environment. To generate each file, there was an excel Macro to do the job.

thanks I feel better now...

[Jeanne Boyarsky]

The mainframe had something called fix cards. This was a file that had the production values. A search and replace was used to create similar files for earlier environments.

Before I knew what fix cards were, I invented the opposite. Have one file that represents the search and replace from development to future environments. We don't maintain them manually and we certainly don't maintain a separate version for each environment.

It is easy to scan this one file of differences to understand what changes exist.

[Tim Holloway]

One of the great thing about Java Properties is how you can stack them and have higher-level property definitions override lower-level (default) ones. The pinnacle of this approach is the Resource Bundle.

I don't like to configure stuff in property files, however, because you have to rebuild the components. I use properties for things that are mostly immutable such as I18N strings. For things that I want to customize more freely, I use more flexible approaches. I can meld them with properties if I like by using Property-style classes that I insert into the property chain.

For small-volume dynamic properties in webapps, I use JNDI - either via container properties or from a directory server such as LDAP. Once I get a dozen or so custom settings, however, this gets awkward. At that point I'm most likely to resort to a database, although an external file is another option. In fact, one technique is to use JNDI to point to an external java properties file!

[Jeanne Boyarsky]

Tim Holloway wrote:I don't like to configure stuff in property files, however, because you have to rebuild the components.

Only if your property files live in the jar. Mine live in a separate directory. We certainly don't rebuild the software to change a property file; that defeats the purpose.

[Tim Holloway]

Jeanne Boyarsky wrote:

Tim Holloway wrote:I don't like to configure stuff in property files, however, because you have to rebuild the components.

Only if your property files live in the jar. Mine live in a separate directory. We certainly don't rebuild the software to change a property file; that defeats the purpose.

There are 4 common ways to access property files. One of the most popular ways is to put the properties in the classpath. In fact, I'm struggling with an app where the original authors did exactly that. I have no problems inherently with properties in the classpath. It makes the app self-contained, and for webapps that's an especially useful trait to have. But, as I mentioned earlier, I prefer to reserve this particular weapon for things that are basically immutable.

For the more dynamic properties, an external properties source is more desirable, since it eliminates the need for a package rebuild. The problem is locating one, and that's the other 3 ways.

You can:

1. Code an absolute property file path into the app. I don't recommend this, although another app I'm working on did it. For several years I was testing webapps under Windows and deploying them on Solaris, and the filesystems are different enough that hard-coded filepaths are best avoided. Also, the app that offends me at the moment can't be multiply-instantiated, since there's exactly one and only one place to find properties, hence only one instance is viable. And we really would like to be able to run a test and production instance and have only one server to do it on!

2. Kludge a property path relative to the webapp installation directory. Please don't.

3. Do what I do and feed the property path in via JNDI.

I think there's yet one other way, but I'm fuzzing out again.

[Evan Caballero]

you can use an environment variable for that.

Imagine that your property files are in the /var/myapp/cfg directory on your system. Instead of harcoding this path in your app, declare an env variable like : MYAPP_CFG_PATH=/var/myapp/cfg
To retrieve this value, use System.getEnv("MYAPP_CFG_PATH");

Then, if you have different configuration files for different environments (dev, prod etc ...) you can use a trick like this one :

declare an env variable for each environment
-> MYAPP_PROD_CFG_PATH = /var/myapp/prod/cfg
-> MYAPP_DEV_CFG_PATH = /var/myapp/dev/cfg

and, before you deploy your application, just switch from one to the other like this :

export MYAPP_CFG_PATH=$MYAPP_PROD_CFG_PATH
or
export MYAPP_CFG_PATH=$MYAPP_DEV_CFG_PATH

This technique is great because it also works on windows. Instead of /var/myapp/prod, you can put D:\var\myapp\prod in the env variable.

Remember, on windows, env variable values are accessible using %MYAPP_PROD_CFG_PATH% instead of $MYAPP_PROD_CFG_PATH on unix. But from the java side, it's the same way : System.getEnv("MYAPP_CFG_PATH");

NB :
this also works for the JAVA_HOME variable, if you use your server to deploy apps with JDK 1.5 and JDK 1.6
declare env like these :
JDK5=/opt/java/jdk5u17
JDK6=/opt/java/jdk6u22
JAVA_HOME=$JDK6 or JAVA_HOME=$JDK5

With all these stuffs, the only thing that is hardcoded in your application, is the name of the env variable.

I hope this will help you ;)

[Tim Holloway]

Evan Caballero wrote:you can use an environment variable for that.

For a stand-alone Java app. And in that context, that's one of the best ways to do it (and/or adding a command-line parameter).

However, I wouldn't recommend using environment variables for webapps. Or, for that matter, for applets, midlets and various other environments where the environment is distant or even disconnected from the Java code.

All things have their place.

[Ulf Dittmer]

This article presents an approach using a annotations: http://nimana.wordpress.com/2010/01/22/using-properties-files-in-java-applications-and-autoload/ Might be interesting just to contemplate other solutions.

[Jeanne Boyarsky]

Tim Holloway wrote:

Evan Caballero wrote:you can use an environment variable for that.

For a stand-alone Java app. And in that context, that's one of the best ways to do it (and/or adding a command-line parameter).

However, I wouldn't recommend using environment variables for webapps.

I use a variable defined on the application server. That variable is then part of the classpath of the web app.

I agree with you that having to repackage to change a property is bad. However, I don't repackage to change a property so I don't have that negative association with property files.

[Evan Caballero]

If you don't want to use env variables, symbolic links under unix can do the trick.

[Suri Vis]

As an extension to this question I'd like to ask the following. One of the things we're trying to do as part of re-addressing our build/deploy processes for applications is to be able to create a "build once" approach to deploy the artifact in all environments - so that the property files remain external and independent of the build. I'm trying to figure out how this can be done effectively and I came across the Apache Commons Configuration project. Not sure if anyone here has experience on it, but the question is, if we have property files for 3rd party libraries such as quartz.properties or displaytag.properties or oscache.properties or even log4j.properties etc. If we were to use the Commons configuration, how would these then be recognized by their respective libraries. I'm not really sure how the Commons configuration works - so any input on either of the areas would be helpful.