Java Webapp: catch 22 regarding dev/prod builds for a .war

Question

There's something I just don't get regarding config files and dev or prod environments.

If you have a .war and want to use the same .war in dev and prod (because the point of the dev environment being, well, to test that the .war is working fine, hence you don't want to test that .war and then deploy another .war right!?), then where do you put the config file telling if your environment is dev or prod?

Say locally I've got user /Users/Alex (on OS X) testing the .war and then, if everything looks fine, I want to deploy on a Linux machine in a /home/tomcat/ repertory.

Where and how do I access the config file telling if it's a dev or a prod environment?

Don't tell me people are building two different .war for dev and prod builds right!? That would kinda completely defeat the purpose...

Answer 1

This is a common problem which has several solutions.

The one which most people (in my experience) seem to use is to have a build script which generates the .war file. The build script can be Ant or Maven, it doesn't really matter - but Ant will require a little bit more work to set up.

You then have a master properties file (or something like that) which contains all your properties for database access etc. in all your different environments. Then, when you run your build script it simply sets the properties in the right places, and you have what is essentially the same .war file - just configured for different environments.

Maven does this pretty much "out of the box" - have a look at profiles.

Answer 2

The best way around it is to build environment specific config outside of your .war. That way you can deploy the same war with separate configuration in different environments.

Getting to the config can be done in a number of ways:

• Place config in the $CATALINA_HOME/lib or similar where it will be loaded in the application server classpath.

• Place it in the home directory of the user that executes the application and point your app to that location.

• Do some JNDI magic (generally this is too difficult for me so I stay clear of it).

To have more certainty about your deploy you can use a deploy tool like Capistrano. Often devs do some pre-deployment sanity checking on prod configuration (obviously it hasn't been tested yet) to make sure the app will run.

Answer 3

You don't want to have to rebuild the WAR to move from one environment to another.

You can externalize configuration to a database, of course, but that won't help much with Spring.

Another thought is to have a configuration file set for each environment, with the name embedded in the names (e.g., "config-devl.xml", "config-test.xml", "config-prod.xml"). Have an environment variable set for each environment that matches the postfix value. Have your app read the config files with the postfix value set by the environment variable on startup.