Wow! Lots of good feedback.. Let me start with the ConfigurationFactory. Okay.. CF sucks.. I discovered the problem with the files myself recently. What it really should work with is an InputStream or Url.. , since the xml file that digester uses could be in a jar. So, I totally agree with you on that.
Okay, second bit, whether a configfactory returns the merged set or properties, or overrides.. I guess there are two seperate usecases. The first usecase, which is what it implements now is that you have a standard set of properties, so you include them in a jar file and use them. But, you want to give the user/deployer the ability to override them, so you put either another properties file or jndi or what not ahead of the standard. And voila! You can override all your properties. Second use case.. I want to collect all the properties from multiple locations and then merge them into one super Configuration object. This would allow me to dynamically add to what is already setup. I think that the ConfigurationFactory should deal with both cases.. I see something like: <override> list of locations to look for properties that override the onces that come after it. Similar to what is there now. </override> <additional> list of locations to add all the properties into one uber Configuration object. </additonal> This would then allow me the ability to do both usecases. I would love to see some patches for ConfigurationFactory, that could support this. As an aside, I wrote an Avalon wrapper for the ConfigurationFactory based Configuration objects: http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html I made it part of fulcrum as I didn't want to bloat c-c with a ton of extra dependencies for something that is just a wrapper. Eric > -----Original Message----- > From: Oliver Heger [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 30, 2003 7:15 PM > To: Jakarta Commons Developer List > Subject: [configuration]Enhanced patch and some thoughts > > > Hi, > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
