AppConfig is a configuration library which provides properties for applications deployed to different environments. For example, your local file storage is located at /home/joe/project1/files in a development environment (laptop), but in production it is located on the NFS: /opt/project1/files.

AppConfig makes it easy to configure multiple property files, one per environment and load just one depending what environment the application is running on.

As such, you may have a property file with content:


while the file will include:


Reading properties

First, import a static import AppConfig.p(...) method:

then, simply call it as: p(..) in places where you need to inject a property:

Property substitution

AppConfig allows a property substitution to make it possible to refactor large property files by specifying a repeating value once.

If your property file has these properties:
phrase= And the name is ${}

than this code will print And the name is John:

Note: The order of properties does not matter.

Setting up for multiple environments

AppConfig allows configuration of applications that is specific for different deployment environments. Applications have environment-specific files, whose names follow this pattern:, where environment is a name of a deployment environment, such as development, staging, production, etc.

You can also provide a global file, properties from which will be loaded in all environments:

In all cases the files need to be on the classpath under directory/package /app_config.

Environment-specific file will have an environment part of the file name match to an environment variable called ACTIVE_ENV. Such configuration is easy to achieve in Unix shell:

A typical file structure


If you are using Maven, then the location will be: src/main/resources/app_config.

Global property file will always be loaded, while others will be loaded depending on the value of `ACTIVE_ENV`` environment variable.

If environment variable ACTIVE_ENV is missing, AppConfig defaults to environment development.

System property override

You can also provide an environment as a system property

Here is an example (add this to the startup script for your app):

The system property points to a file specific to that computer (local box, server, etc.). If a specific property is provided in the properties file loaded on classpath, and the same property is also found in the file, then the value loaded from a local file overrides the one loaded from classpath.

Environment Variables Override

Sometimes the DevOps will not allow production passwords and other sensitive data to placed in the source code. If this is the case, any property defined in the environment - specific property files can be overridden by a system environment variable. As long as that environment variable named exactly the same as the property, its value will override the one from any file (internal or external).

Watch out for log lines like: Duplicate property defined?. in case of a duplicate value override. It will tell you exactly where the new value is coming from and which property source is overridden with it.

How to comment

The comment section below is to discuss documentation on this page.

If you have an issue, or discover bug, please follow instructions on the Support page