commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] What changes in Commons Configuration 2.0 ?
Date Sun, 17 Feb 2008 17:14:01 GMT
In most points I agree. Some comments below:

Emmanuel Bourg schrieb:
> Hi,
> 
> I'd like to open the discussion on the changes we'll implement on the 
> 2.x branch. Here is a list of the things I have in mind :
> 
> 
> Cleanup
> 
> - Remove ConfigurationFactory, its use is deprecated since the 
> introduction of ConfigurationBuilder. This removal will allow us to drop 
> the dependency on Digester.
+1

> 
> - Remove the deprecated classes and methods 
> (HierarchicalXMLConfiguration and several methods here and there)
+1

> 
> - It may be possible to drop the dependency on JXPath since Java 5 comes 
> with it's own XPath implementation (in the javax.xml.xpath package). I 
> wrote a quick test and I've been able to query a 
> HierarchicalConfiguration with the standard classes. I'll try to 
> implement an ExpressionEngine from this prototype.
Let's test this out. However I would like to modify the ExpressionEngine 
interface slightly to offer more features.

> 
> 
> Refactoring
> 
> - New package name, with no version number please. I suggest 
> org.apache.commons.config
I prefer going with the commons standards here. I am against a config 
package because it is unrelated to the existing configuration package. A 
package name of configuration2 shows that the API is evolving.

> 
> - Merge the methods of DataConfiguration into the Configuration 
> interface, and remove the methods that can be generified. For example 
> there is no need for getBigDecimalList(key, defaultValue) if 
> getList(String key, List<T> defaultValue) is available.
For the extended data types we can have a generic
<T> T get(String property, Class<T> valueClass)
method. This can be combined with the pluggable converters mentioned below.

> 
> - Make all configurations hierarchical by default, that means merging 
> the methods of HierarchicalConfiguration into the Configuration interface.
+1.
I have some ideas for hierarchical configurations that do not operate on 
ConfigurationNodes and thus do not keep all their properties in memory. 
A PreferencesConfiguration or an improved JNDIConfiguration could be 
based on this.

> 
> - All configurations being hierarchical, the Configuration becomes the 
> tree node. This is similar to the Preferences API. SubsetConfiguration 
> can be abandoned.
I am not convinced by this. Will have to see how this looks like in 
practice.

> 
> - Adopt the concept of flush() / sync() from the Preferences API to make 
> all configurations persistence-aware. This would allow us to merge 
> FileConfiguration with Configuration and greatly simplify the existing 
> code. This will allow to save the changes in a DatabaseConfiguration in 
> an efficient way with the same save() or sync() method used for the file 
> based configurations.
+1

> 
> - Should we turn Configuration into an abstract class to allow the 
> addition of new methods later ?
Interfaces are fine IMO. For instance, they allow for a better 
testability using mock objects.

> 
> - Make the file based configurations reloadable by default. The 
> FileChangedReloadingStrategy replace the InvariantReloadingStrategy as 
> the default strategy.
I am not that happy with the current approach to reloading. Maybe we can 
come up with something better.

> 
> 
> New features
> 
> - Bridge with the Preferences API, that means implementing a 
> PreferencesConfiguration class to use a Preferences as a Configuration, 
> and a ConfigurationPreferences do to the opposite.
> 
> - Introduce the Locators ? The use of a locator should remain optional 
> to keep the API easy to use.
The current way of dealing with files and file names is complex, and the 
API is bloated with lots of get and set methods. We have now the chance 
of changing this. So why not go for locators? This will be a hard break 
for configuration 1 users, but on the long run I think we are better off.

> 
> - Implement a pluggable conversion mechanism for the values stored in 
> the configurations. This may rely on Morph or Beanutils. This is a low 
> priority though.
> 
> 
> Emmanuel Bourg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message