Where do you keep your environment-related configuration?

[nlif]

Hi,

When developing a JEE web-app which is deployed as a WAR, where do you keep your environment-related configuration (e.g. database URL, various login credentials etc.)?

For example, let's say that certain values are different on development workstations, QA machines, and production servers. Now, if there is a single configuration file which is somewhere inside the WAR file, then upon deployment, it will be overwritten, thus losing all local-machine settings. Furthermore, upgrading to a new version of the application should not be related to the configuration settings of the machine.

AFAIK the JEE standard does not state how this should be handled, nor is there a mechanism for this.

I'd be happy to hear how people deal with this issue.

Thanks,
Naaman

ps

I realize this is not a "spring-issue", in that it is not a result of using Spring. Nevertheless, since our architecture is based on Spring, I was wondering whether Spring offers a solution, or if there is at least an established best-practice or convention for dealing with this issue.

[kantorn]

JNDI comes to mind, it's designed for cases where machine specific configs are needed. Other not so common solutions is a file system based config file or similar.

[chudak]

http://forum.springframework.org/showthread.php?t=61733

http://forum.springframework.org/showthread.php?t=61547

[CodeKing]

http://www.springsource.com/whitepapers

[danielp]

As a general rule it is a bad idea to leave the properties file in the EAR/WAR file because you have to edit the deployed ear and potentially have to rebuild (depending on deploy process) every time you deploy. This may be alright for the people who build the application but new staff will have a hard time with this and may cause deployment failures because someone did not know to update the properties file in the EAR/WAR when it really did not need changing.

The simplest thing to do is put the file on the class path and then configure a classpath where to the location of your properties file so that it is always avaliable to your application and can be changed independant of the EAR/WAR deployment.

The next level I would look at is getting database connections from A datasource configured in the App server using JNDI. This would allow you to reconfigure the connections without having to build your own mechanism to give properties to the driver it may also hide passwords for you. The exact features avaliable depends on the app server your using.

If there are still properties that are not required for the db connection such as file locations you could do both. e.g. Datasources and Mail providers come from the app server and the other details come from the properties files. This helps the admins know what your application needs.

If you get your connection from the app server then your could consider putting your other properties in the database. This is most useful in a clustered environment where the appservers cannot share a single classpath.

There are some useful tools for managing properties in the commons configurations project and there is and example of using database properties with commons configuration and spring in springbyexample.org

[chudak]

As a general rule it is a bad idea to leave the properties file in the EAR/WAR file because you have to edit the deployed ear and potentially have to rebuild (depending on deploy process) every time you deploy. This may be alright for the people who build the application but new staff will have a hard time with this and may cause deployment failures because someone did not know to update the properties file in the EAR/WAR when it really did not need changing.

It may be YOUR general rule but I don't think it qualifies as A general rule.

Putting properties in the database adds unnecessary complexity if the properties rarely change and/or do not need to be changed between deployment cycles. You never have to edit the deployed ear. Frankly, if you HAD to support a new deployment environment, you could just add the new property file and drop it on top of the existing WAR/EAR until the app was rebuilt and redeployed.

[constv]

Actually, a lot of what danielp is saying makes sense. The only properties you should put into the EAR/WAR are the ones that may be considered implementation details of your application components/services. Those are basically the same as code and should not be messed with after the app is deployed. The properties that are meant to be configurable absolutely must reside outside the EAR/WAR. Like chudak, I hate storing properties in the database, and I prefer using JNDI (e.g. for data source configuration) and files available via classpath. However, as danielp has noted, it may raise an issue of replicating any property changes on clusters.

[Goran]

We have a couple of applications where we have externalized the property files in a simple fashion using the "user.home" property as the location. In the root of this directory we simply put a hidden .appname directory that contains configuration files. Works fine with a mix of both windows and unix environments.

If you are running on Linux make the hidden directories in your home folder visible, and you will see numerous examples of this type of directories.

G

[nlif]

Thanks for all the replies, this is useful information. BTW - the white-paper is also a very good read.

Why is there such dislike to keeping configuration in the database? We have found this is several advantages, such as: that most of the configuration is the same for all servers in the cluster.

Furthermore, properties are limited to key=value pairs, while there is sometimes need for more complex requirements (e.g. hierarchical).

Naaman

[constv]

Thanks for all the replies, this is useful information. BTW - the white-paper is also a very good read.

Why is there such dislike to keeping configuration in the database? We have found this is several advantages, such as: that most of the configuration is the same for all servers in the cluster.

Furthermore, properties are limited to key=value pairs, while there is sometimes need for more complex requirements (e.g. hierarchical).

Naaman

You are absolutely correct: in some cases it makes sense to keep configuration data in the database, and there is nothing wrong with that. My #1 criterion, however, is "keep things as simple as you can." Properties files are the most convenient and easy way to use/maintain/refactor during development, and in deployment - unless, as you have said, clustering imposes additional requirements. Values from properties files are very easy to read and load (you need to do almost nothing to make your properties available to your spring beans.) It is definitely my choice for those configuration properties that should not be changed between releases. Storing such things in the database adds more unnecessary complexity.