Switching Application Required System Properties According to Deployment Environment

Any serious application depends on a number of configuration properties, such as JDBC connection properties, caching properties etc. They should change according to target deployment environment.
People employ different methods to take those properties outside their web applications. Among them, one commonly used method is to create a properties file and collect any property, whose value should change depending on the current deployment environment, then create variations of that properties file for each deployment environment. During build process, which property file should be taken into account is specified via another parameter, for example an environment property or system property.
We currently employ a similar method in our current project. We use ant in our build process, and have defined an ant global property named target.environemt, taking values dev, test, or prod accordingly. We, then, use following construct in our build.xml to customize our build process according to target deployment environemt.

<property file=”build.properties.${target.environment}”/>

Thus, we load specified build properties file to customize our build process according to the target environment. We use, for example, tomcat as web container and its ant tasks to deploy, stop, and start our web application. Development, test and production environments are simply located in different physical servers, and accesible with different user credentials. In order to make use of same tomcat ant task for each target environment, we keep tomcat server url, port, credential information in this build properties file.
When it comes to customize our application configuration properties, we simply copy specified project.properties.${target.environment} file into web application classpath while stripping off the suffix at the end. As the old saying goes, a layer of indirection solves every problem in computer science.
Karl Baum has a nice blog entry about this topic and gives a solution based on above method, but it is much more flexible as it enables us to switch between configurations without a new build or deployment at all.a