Handling of configuration files in Spring web applications

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

Answer 1

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.

Answer 2

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

Answer 3

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.