Question

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 appcontext)
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?

Answer 1

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