Tracking changes with Apache Commons Configuration

Question

For an upcoming project I am planning to use Apache Commons Configuration.

I would like to use the library for reading and writing all configurations of the given application from/to a database.

We have the requirement that all configuration changes are tracked (or configurations are versioned). This change tracking should also be stored in the database.

Configuration changes are not happening very often.

I wonder what would be the best approach to implement this change tracking functionality? Is there some support in Apache Commons itself? Is there another suiting framework/library?

Answer 1

I don't think there's any overlap between Apache Commons Configuration and your requirement for a change tracking configuration database, unfortunately.

If you need to store the configs in a database I suspect you'll either need another framework or roll your own solution. Re. the database, 2 thoughts:

1. you can store configs with a valid-from/valid-to date. The current configuration would be the one with the null valid-to date, and you'd set the valid-to date as you update the config
2. some databases support the notion of versioned data. E.g. Oracle has a flashback capability in which you simply re-write the database entity, and Oracle records a version of that table at that time (the specifics are probably much more complex). That may be a useful solution if you simply want a history of config changes for audit purposes.

Another solution is to manage your configurations using an SCM, and to package/deploy such configurations with releases. e.g. create dev/test/prod configs in your source code repository and manage the changes there. Wrap these configs in your deployable and release to the appropriate environments. You have the change tracking capability of the SCM, but you can't easily track a change that occurs on the deployed environment. Your change management processes may/may not allow this.

An amended version of the above would allow you to use your SCM solution on your deployed environments e.g. to check out configs into your prod environment. I've not seen this used a lot, I confess. It means a bridge/dependency between your development and production environments and that may be a bridge too far.