Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Use the Force: Attaining Low-Risk Application Configuration Management

So what’s the Problem with Application Configuration Management anyway?

You know how when you are trying to deploy an application to another environment, and then it starts to suck because somehow you end up with the wrong version of the configuration or the configuration values are for a different environment altogether?

This is not an uncommon problem – many development teams around the world struggle with application configuration management – especially when there are multiple deployment sites. If the app needs settings to operate properly, how should those settings be managed and what are the criteria for proper management?

In this post, we review how to manage application configuration in a low-risk way, several approaches that have been implemented as solutions: external system property, multiple application bundles, and external configuration.

Application Configuration Management in Specific Environments

Application distribution management via repositories feels natural to any Java developer, but when it comes to environment specific configuration we lack a silver bullet. Even in a two-person team you will get three opinions about a proper solution. This gets even trickier when you have custom install sites for each client or when the application has to move automatically through different environments in a continuous delivery pipeline.

So what does it mean to have your configuration managed? Usually we look for the same attributes in the case of any data:

  • availability to all necessary parties
  • recoverability
  • traceability

Availability should include automated tools in addition to personnel. So versioning in a source code repository is a good start for configuration management. Since Version Control Systems (VCS) – like SVN, Git & Mercurial – have been in common usage for over a decade, it also makes configuration easy to work with. Recoverability and traceability are obviously part of the picture.

Configuration by itself does not hold much value, so it’s equally important to apply the same criteria to bundled applications. In general, there’s three basic approaches to this:

  • In the deployed application, include all possible configurations and features, then select which ones are active based on a system property, set outside the app.
  • Build different bundles depending on the final deployed configuration.
  • Load the environment configuration from outside the application (e.g. JNDI, file located on the file system, etc)

Scenario 1 – External system property

One of the simplest approaches and especially well suited for in-house product development is to have one deliverable with all the necessary configuration bundled with the application. System property can then be used to pick appropriate settings for the environment.

Properties properties = new Properties();
try {
        String env = System.getProperty(“environment”, “default”);
	properties.load(new FileInputStream(env + “.properties”));
} catch (IOException e) {
	System.err.println(“Something broke.”);

Environment property can come from:

  • -D jvm parameters
  • Context parameters within the container
  • JNDI

Scenario 2 – Multiple application bundles

In some cases it is not viable due to internal policies or sensitivity to bundle the configuration with application and we need different bundles for each environment. Ant builds could be used, but this cannot usually be considered a managed application – you still have to make it available to all parties somehow.

A better solution would be to use Maven profiles together with classifiers and have the artifacts stored in a Maven repository.


This is not ideal, but is relatively simple to implement and understand. Since the artifact is different per deployment site, errors can sneak in – errors in packaging or stale configuration.

Scenario 3 – External configuration

The last common approach is to use an external source for configuring the application.

A common format for Java applications is to use java.util.Properties and save/load these properties from a file:

Properties properties = new Properties();
try {
	properties.load(new FileInputStream(“/global/path/”));
} catch (IOException e) {
	System.err.println(“Something broke.”);

This has the advantage of allowing very simple external configuration (say through configuration management tools like Puppet). Operations team do have to be careful about making sure that the configuration file exists and is up-to-date.


Application configuration management still remains a problematic topic for many, with solutions reinvented and customized for specific situations and use cases. If we take control of configuration management, it becomes easier to distinguish between the pros & cons of each approach, letting us focus on specific needs of the organization’s process and environments.

At ZeroTurnaround, we have generalized common solutions to this problem and while they vary from organization to environment, the core ideas are simple enough to implement on your own.

I’d enjoy hearing about your own solutions as well – feel free to drop me a line at – and may the force be with you!