What is the best way to manage configuration data

Question

I am working on a product suite which has 4 products. Right now, all of the configuration data is either in the XML or properties files.This approach is not maintainable as

Answer 1

You're almost there... I would keep your same approach and pull in the correct configuration file for the instance of the application that is running by a method similar to either of the following:

1. Name all of your configuration files differently and have your application pull them in by some unique criteria (username, hostname, etc.):

   • production.properties
   • developer1.properties
   • developer2.properties

2. Keep them outside the codebase in a location based on an environment variable that the application assumes exists:

   • YOURAPP_CONFIG_DIR/server_config.xml
   • YOURAPP_CONFIG_DIR/database_config.properties

I've even used a combination of these approaches on the same project (#1 for build process configurations and #2 for runtime configurations).

Answer 2

If your applications work with a database, you can create a "configuration" table as follows:

create table configuration (mode char(3), key varchar(255), value varchar(1023));

You would initialize it using an init script, say init.sql with contents along the lines of:

insert into configuration values ('pro', 'param1', 'value1'); -- production
insert into configuration values ('dev', 'param1', 'value1'); -- development
insert into configuration values ('tst', 'param1', 'value1'); -- testing
...

The benefits of this approach are as follows:

• you version the script together with your code
• you can easily extend it to include per-user or per-group settings by adding a user/group id
• you can change the settings at runtime if you need to do so
• you get to use the same stack (JPA + DAO, Cayenne...) you normally use to handle core application data to handle configuration data

Answer 3

Config is a configuration file management tool. You can create configuration that is common on all environments, or you can create an environment specific configuration. You can keep using your XML and properties files, and let Config maintain the differences in environment. You can think of Config as your centralized database and it can output the configuration file in the format that you want. Whenever you want your configuration file, just deploy (push or pull) it from Config to your desired location. Note that I'm part of the Config team.

Answer 4

Environment variables are just about the easiest way to go. Set them as you would any other time, access them w/ System.getenv("...")

Answer 5

Using commons-configuration you have a unified API for accessing the properties, no matter how they are represented - .properties, xml, JNDI, etc. For example:

config.properties:

jdbcHost=192.168.12.35
jdbcUsername=dbuser
jdbcPassword=pass

config.xml:

<config>
   <jdbcHost>192.168.12.35</jdbcHost>
   <jdbcUsername>dbuser</jdbcUsername>
   <jdbcPassword>pass</jdbcPassword>
</config>

in both cases they will be accessible with something like:

String host = config.getString("jdbcHost");

Answer 6

There are plenty of different strategies. All of them are good and depends on what suit you best.

1. Build a single artifact and deploy configs to a separate location. The artifact could have placeholder variables and, on deployment, the config could be read in. Have a look at Springs property placeholder. It works fantastically for webapps that use Spring and doesn't involve getting ops involved.
2. Have an externalised property config that lives outside of the webapp. Keep the location constant and always read from the property config. Update the config at any stage and a restart will be up the new values.
3. If you are modifying the environment (i.e. application server being used or user/group permissions) look at using the above methods with puppet or chef. Also have a look at managing your config files with these tools.