I agree that all file based configuration classes should work the same way.
I have an alternative suggestion: We could introduce a new package o.a.c.configuration.io with a couple of ConfigurationReader and ConfigurationWriter classes. The Readers would be initialized with a file, a URL or whatever and have a read() method that returns a Configuration object. The Writers would have an analogous write() method that stores a given Configuration object to a specified destination.
In my opinion this would have two advantages:
1. The logic of loading and storing data is extracted from the Configuration classes. In fact we would only need one or two Configuration classes that are only responsible for maintaining properties.
2. It would be possible to store a Configuration with a different Writer than it was loaded. So it would for instance be possible to read a properties file and save it as XML file.
Well, this would certainly cause more work, so it probably cannot be addressed before the 1.0 release. But what do you think about this idea in general?
Oliver
Emmanuel Bourg wrote:
Hi all, I'd like to suggest a change to something in [configuration] that has been itching me for quite some time: the inconsistencies between the various file based configurations with regard to data persistence.
Currently we have several inconsistent constructors, and load()/save() methods between PropertiesConfiguration, XMLConfiguration and HierarchicalXMLConfiguration. For example, XMLConfiguration can be constructed from a File object, but not the others, HierarchicalXMLConfiguration can be loaded from an URL but not saved, PropertiesConfiguration can be loaded directly from an InputStream, etc.
There are also exception inconsistencies, for example save(OutputStream) throws a ConfigurationException in XMLConfiguration and an IOException in PropertiesConfiguration.
I summarized these differences in the attached excel sheet (I hope everyone can read it, if not I'll export it to HTML). I think in order to provide a clean and well thought out API we must implement the same methods everywhere. Hence I suggest the following:
- replace BasePathLoader with a FileConfiguration interface. This interface will declare the load/save methods and the get/setters for the file name and the base path.
- replace BasePathConfiguration with AbstractFileConfiguration. It provides a default implementation for the get/setters and for some load/save methods.
- complete PropertiesConfiguration, XMLConfiguration and HierarchicalXMLConfiguration with the missing constructors and methods.
What do you think ?
Emmanuel Bourg
------------------------------------------------------------------------
--------------------------------------------------------------------- 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]
