Monday, September 25
Configuration using Jakarta Commons
I've played around quite a bit with the Jakarta Commons libraries over time and over several projects. Among these, the Jakarta Commons Configuration library is extremely useful.
Very often, we encounter a particular crosscutting concern when developing medium to large scale projects: that of managing user and/or application preferences. This seemingly simple task often leads to much wasted and duplicated effort when the development team should really be focusing on core project tasks. The Commons Configuration library can come to the rescue in such situations.
Managing user/application preferences can get complex depending on the requirements. Consider:
(1) The project may start out storing configuration information in simple ".properties" files, but later, some genius might want to migrate everything to XML files. In such instances, you want the property accessor calls abstracted out enough so that the migration can take place with minimal, localized code change and without breaking property accessor calls which might be sprinkled throughout the codebase.
(2) You might want to support a hierarchy of property sources. For example, you might have an application-wide property source that provides the default values, but allow each user to specify his or her own property file to override the defaults. In other words, you need to support multi-source, composite configurations.
(3) You will in some cases want to support nested and/or list-based properties in your properties files.
(4) You will want to synchronize access to shared properties files in case of concurrent updates.
(5) You might want to provide an "autosave" feature or an "auto reload" feature when a preference/property is updated.
Well, the Jakarta Commons Configuration library goes a long way in providing a very flexible framework for configuration/preferences management. It supports ".properties" file based configurations and XML files. The accessor syntax for the XML files is XPath-like and can get quite intricate, I noticed.
A wonderful feature is the provision of configuration change listeners which can listen for changes to a properties file and respond appropriately. Any Java class can set itself up as a listener to a Configuration object, which fires the required events.
I have yet to compare the Jakarta Configuration library with the Preferences API in Java, but from a cursory glance, it seems to me like the Preferences API does not even come close in power. Also, the .Net System.Configuration classes seem to be much more specific in the sense that they seem to concentrate on providing access to the .Net framework config files like machine.config and web.config and not so much on supplying a flexible and generic configuration management framework.
Wishlist: A nice addition to the Commons Configuration library might be access methods to configuration data stored in relational databases and hierarchical stores like LDAP, but that is probably asking for too much.
Very often, we encounter a particular crosscutting concern when developing medium to large scale projects: that of managing user and/or application preferences. This seemingly simple task often leads to much wasted and duplicated effort when the development team should really be focusing on core project tasks. The Commons Configuration library can come to the rescue in such situations.
Managing user/application preferences can get complex depending on the requirements. Consider:
(1) The project may start out storing configuration information in simple ".properties" files, but later, some genius might want to migrate everything to XML files. In such instances, you want the property accessor calls abstracted out enough so that the migration can take place with minimal, localized code change and without breaking property accessor calls which might be sprinkled throughout the codebase.
(2) You might want to support a hierarchy of property sources. For example, you might have an application-wide property source that provides the default values, but allow each user to specify his or her own property file to override the defaults. In other words, you need to support multi-source, composite configurations.
(3) You will in some cases want to support nested and/or list-based properties in your properties files.
(4) You will want to synchronize access to shared properties files in case of concurrent updates.
(5) You might want to provide an "autosave" feature or an "auto reload" feature when a preference/property is updated.
Well, the Jakarta Commons Configuration library goes a long way in providing a very flexible framework for configuration/preferences management. It supports ".properties" file based configurations and XML files. The accessor syntax for the XML files is XPath-like and can get quite intricate, I noticed.
A wonderful feature is the provision of configuration change listeners which can listen for changes to a properties file and respond appropriately. Any Java class can set itself up as a listener to a Configuration object, which fires the required events.
I have yet to compare the Jakarta Configuration library with the Preferences API in Java, but from a cursory glance, it seems to me like the Preferences API does not even come close in power. Also, the .Net System.Configuration classes seem to be much more specific in the sense that they seem to concentrate on providing access to the .Net framework config files like machine.config and web.config and not so much on supplying a flexible and generic configuration management framework.
Wishlist: A nice addition to the Commons Configuration library might be access methods to configuration data stored in relational databases and hierarchical stores like LDAP, but that is probably asking for too much.
# posted by Sougata : Monday, September 25, 2006
Subscribe to Posts [Atom]