Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to differentiate between test and production properties in an application?

We're developing a big J2ee e-sales solution. It's got a lot of integrations: CMS, ERP, Mail server etc. All these systems are divided into test and production environments.

We need to deploy our application to our test servers with test configuration and when deployed to our production servers it should use the production configuration. How do we make our application select the correct properties?

The thing we've tried so far is this:

All our property files contain test properties and production properties

test.mvxapi.server = SERV100TS
test.mvxapi.username = user
test.mvxapi.password = password
test.mvxapi.port = 6006
test.mvxapi.cono = 600

mvxapi.server = SERV10001
mvxapi.username = user
mvxapi.password = password
mvxapi.port = 6001
mvxapi.cono = 100

The Util that reads these properties has a switch: isTest() which prefixes the key with "test."

public String getProperty(String property)
{
    return properties.getProperty(prefix + "" + property);
}

The switch is set by another property which is created by our build server. When the .EAR is built the script for our production servers injects (input to build.xml) "isProduction=true" into system.properties.

<propertyfile file="${buildDir}/system.properties">
        <entry  key="isProduction" value="${systemType}"/>
    </propertyfile>

I'm not sure this is the best way to do it. If for some reason "isProduction=false" is committed wrongly to our production environment all hell is loose.

I've read people have properties locally on the server. But we really don't want to have files spread around. We have cluster of production servers. Making sure every server has the right property file doesn't seem fail-safe

like image 337
Tommy Avatar asked Jul 22 '09 19:07

Tommy


2 Answers

What you want to avoid is having the config file inside the EAR, the problem with this is that you need different EAR's for different environments, and also, changing the config file requires a rebuild.

Rather deploy the same EAR to every server but configure each server with a different URL resource. iow, add a JNDI URL resource to all the servers you deploy to that point to the config file for that resource. If you have read only SVN access to your repo then create the config files on the svn repo, or any repo you can access via a URL. The cool thing here is that all your configuration is centralized and thus managing them is easy.

What I've done (by customizing with spring) is make sure that JNDI URL resource optional. So, if it's there, the app will use it, if not, it won't. The app starts up whether it's there or not. That way, even when running with no JNDI resource available, the app still works (development environment for example).

like image 186
Michael Wiles Avatar answered Nov 11 '22 01:11

Michael Wiles


You deploy an EAR? Then put the properties needed in JNDI.

like image 40
Thorbjørn Ravn Andersen Avatar answered Nov 11 '22 01:11

Thorbjørn Ravn Andersen