I have added an enhanced version of the HierarchicalConfiguration patch to bugzilla (because of its size): Bug 24262. In this patch there is also an XMLReader implementation that operates on a BaseConfiguration instance rather than HierarchicalConfiguration. This makes it possible to perform XML processing on all kind of Confiugration objects and e.g. pass them to a Digester.
The new parsing functionality for (Base)Configuration objects is implemented in the BaseConfigurationXMLReader class. There is also a new base class ConfigurationXMLReader that provides common functionality of the specific XMLReader classes. An additional class HierarchicalConfigurationConverter is used by BaseConfigurationXMLReader and provides means to iterate over the keys defined in a Configuration and treat them in a structured manner.
I am expecting your feedback...
Finally some thoughts about ConfigurationFactory: This class and some of the Configuration classes that can be created by this factory load their data from files. I think that will cause problems for applications that are deloyed in jars (and that have their configuration also stored in these archives), e.g. web applications. Wouldn't it be better if the affected classes used URLs instead? Then it would be possible to determine a URL to a configuration file (even if it is located in a jar) in a simmilar way as ClassPropertiesConfiguration work and let the classes read their data from that URL.
And still another point: I am not very happy with ConfigurationFactory in the way that it not really constructs a union of the properties it reads. For instance if two XML files are read that contain similar elements you cannot obtain the data in the second file because the search for properties stops when values in the first file are found. I would prefer to get all properties.
The BasePropertiesConfiguration class provides a way of including other files into a property file. I think it would be very useful to implement this feature for other configuration classes, too. Maybe a generic approach could be found to allow includes of arbirary files in all configuration classes (e.g. include .properties files in XML files and vice versa, XML files in XML files etc.). With this approach a developer could access all properties in his application through a single configuration object; this is similar to a Unix file system which allows to mount different disks into one logic directory tree.
As a use case consider web frameworks like struts. Those frameworks typically define lots of configuration information in a monolithic file (struts-config.xml), which can be a bottle neck in large projects with lots of developers. With the generic include facility it would be very simple to split these large files into arbitrary small portions and link them together. For the code that processes the configuration these portions occur as a single logic file.
What do you think?
Regards Oli
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
