I have several times ran into the same problem, and I would like to have some input on what other people think about the issue: Suppose we have Spring application packaged as a .war file and we want to run it on several environments. (development/test/preprod/prod/etc)

For accessing the infrastructure needed by the application, (databases/webservices etc) we store the access info in configuration files, also some business configuration is in those files. Let's say we use .properties files for this purpose (because we have a spring application inside the war and we like having the properties read by a one-liner in the appco开发者_开发问答ntext) and also suppose that in the different environments we don't have the same appserver/servlet container. (eg: dev, test: jetty, preprod: tomcat, prod: glassfish)

What I usually have done is creating multiple Maven profiles, one for each environment, the needed configuration in the appropriate files for each.

Now recently I have faced a question from a guy running operations: 'So really we have to generate a new build with the appropriate profile on the buildserver if the DB is changed in preprod environment?' I answered 'No, you can actually go to .../webapps/currentApp/WEB-INF/classes/config/application.properties and change the values there, then restart the container'

We have come up with a solution which solves some aspects of this issue: using Maven assembly plugin we embed a Jetty inside the war which makes it usable as an 'executable' war, also giving us the possibility to have a global configuration XML, from which the starter of the embedded Jetty creates/modifies the appropriate .properties files in the exploded war directory and only then starts the application.

But again this doesn't solve the issue if you want to use anything else other than Jetty.

How is everyone dealing with the same situation?

Environment variable, external config files

We have something similar, a Web Application running in Tomcat/Weblogic with Spring. What we do is define a environment property CONFIG_PATH and put all the XMLs (including spring config) and properties files in that directory.

We have multiple properties files (per environment) that we send it as a tar file. The Web app loads all the Properties/Spring config files from the CONFIG_PATH directory. This variable is defined as Environment variable in the respective environment

This way we are not touching the WAR file nor building separate WAR for environment. Think of this scenario: QA & PROD WAR files built, QA tested QA war file, PROD WAR deployed in PROD but something blows up :(

We do something as below:

In spring config xml, we define:

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="order" value="0"></property>
    <property name="locations">
        <list>
            <value>file:${CONFIG_PATH}/App.properties</value>
        </list>
    </property>
</bean>

Refer all variables as usual in spring config.

In web.xml we define spring config as below:

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>file:${CONFIG_PATH}/**/spring-config.xml
    </param-value>
</context-param>

The QA/PROD team deploys the same artifact with their corresponding environment files. If something blows up we know its only the env. properties that are messed up. HTH

Database

Developers can't touch a WAR once it goes to an environment where I work, so if we need to change a configuration value without re-deploying we put it in a relational database.

Those don't require a repackaging, redeployment, or bounce of a server. The app does have to refresh read-only configuration periodically, though.

JNDI

JNDI settings remain fixed from environment to environment; those changes are set up once by the app server admin and don't change. (See Oracle Tutorial)

I'm talking about name/value pairs for configuration for the app itself, not JNDI.

For data sources; it is a common approach in tomcat context to create a JNDI resource entry and decouple your resource entries/configs from your application. If DB is changed, then you can reconfig your JNDI resource in your container (Tomcat,Jetty etc.) and restart. If you have a container farm, then it won't be a problem to restart your tomcat instances. you can deactivate them on load balancer and restart, reactivate. I think that there is a context file in Jetty also in which you can add JNDI resources. Moreover there is maven profiles for t he properties which depend on different contexts. you can select your profile with "-P" parameter of maven, and your project will be built with these configs, for example for the different target contexts like live and test.