Overriding a packaged Spring application properties file via an external file

A common use case when developing a Spring application is the requirement to have multiple versions of configuration properties which vary depending on the target environment you are deploying to. For example, a database URLs or a feature flag may be environment specific, and the value you use for local (dev) testing may be significantly different than on QA or production etc.

Like most Spring development tasks, there are several way to solve the problem. My preference is based on the following assumptions and preferences:

  • We create a default configuration properties file (e.g. ‘appConfig.properties’) and package this within the deployable artifact (JAR or WAR etc)
    • This file will contain a sensible set of default ‘baseline’ properties that the application requires to run successfully
    • This default configuration file will typically be used for development purposes i.e. the  appConfig.properties included within the application code will allow the application to work ‘out of the box’ on a well configured local development box
    • We are using Maven to package our application, and therefore we place the appConfig.properties file in the root level of the src/main/resources directory – this doesn’t mean you have to use Maven, but you will have to ensure that your application packaging process includes the properties files in a location that is on the classpath
  • We want to override properties in the baseline appConfig.properties file via an external file located in the deployed application’s working directory
    • We typically name this file appConfigOverride.properties
    • We may not override all of the default properties, and therefore we want any properties not present in the override file to default to the values in the baseline appConfig.properties file
  • It is possible to override application properties by passing parameters on the Command Line when executing the application, or setting system variables, but this is a separate topic :)

The Solution

We use the following structure for our application-context.xml:

The key things here, are the ‘order’ attribute, which forces properties found in the appConfigOverride.properties to be used when a property is also found in another file (effectively overriding values from the other file), and the ‘ignore-unresolvable=”true” ignore-resource-not-found=”true”‘ which allows Spring to continue loading the context if it can’t find the external file (or it doesn’t contain override all of the default properties from the appConfig file)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: