Can I use a single war file in multiple environments? Should I?

Question

I have a Java web application at my work and I'd like simplify how we deploy to our DEV, QA, and PROD environments.

The application reads in a series of properties at startup, and the properties files are different for dev, qa, and prod. Whenever I want to deploy to a certain environment I drop the environment-specific properties file into my app folder, build the war, and then deploy it to one of the three tomcat 5.5 servers.

What I would like to do is have to have a single .war that has the properties for all environments, and have the app interrogate the webserver during the init process to figure out which environment the app is in, and hence which properties to load. Is there an easy way (or, failing that, a standard way) to do that?

Answer 1

This really depends on what you are using those properties for.

Some (like data source, for example) can be configured in the container itself (Tomcat 5.5. JNDI Resources, see JDBC sources section as well).

Others (application-specific) may indeed need to be properties. In which case your choices are:

1. Bundle properties within WAR file and load the appropriate subset based on some external switch (either environment variable or JVM property)
2. Setup a deployment process on each of your servers where war is unpacked and a property file (located in a predefined location on that server and specific to that server) is copied over to WEB-INF/classes (or other appropriate place).

As far as "is this a desirable goal" goes - yes, I think so. Having a single WAR to test in QA / staging and then deploy to production cuts out an intermediate step and thus leaves less chances for mistakes.

Update (based on comment):

Item #1 above refers to an actual environment variable (e.g. something that you set via SET ENV_NAME=QA in Windows or ENV_NAME=QA; export ENV_NAME in Linux). You can the read its value from your code using System.getenv() and load the appropriate properties file:

String targetEnvironment = System.getenv("TARGET_ENV"); String resourceFileName = "/WEB-INF/configuration-" + targetEnvironment + ".properties"; InputStream is = getServletContext().getResourceAsStream(resourceFileName); Properties configuration = new Properties(); configuration.load(is); 

But yes, you can instead define a scalar value via JNDI (see Environment Entries in Tomcat doc) instead:

<Context ...>   <Environment name="TARGET_ENV" value="DEV" type="java.lang.String" override="false"/> </Context> 

and read it within your app via

Context context = (Context) InitialContext().lookup("java:comp/env"); String targetEnvironment = (String) context.lookup("TARGET_ENV"); // the rest is the same as above 

The thing is, if you will be using JNDI anyway, you might as well forgo your property files and configure everything via JNDI. Your data sources will be available to you as actual resources and basic properties will remain scalars (though they will be type safe).

Ultimately it's up to you to decide which way is better for your specific needs; both have pros and cons.