commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@apache.org>
Subject [configuration] What changes in Commons Configuration 2.0 ?
Date Sun, 17 Feb 2008 14:10:19 GMT
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.

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

- 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.


Refactoring

- New package name, with no version number please. I suggest 
org.apache.commons.config

- 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.

- Make all configurations hierarchical by default, that means merging 
the methods of HierarchicalConfiguration into the Configuration interface.

- All configurations being hierarchical, the Configuration becomes the 
tree node. This is similar to the Preferences API. SubsetConfiguration 
can be abandoned.

- 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.

- Should we turn Configuration into an abstract class to allow the 
addition of new methods later ?

- Make the file based configurations reloadable by default. The 
FileChangedReloadingStrategy replace the InvariantReloadingStrategy as 
the default strategy.


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.

- 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


Mime
View raw message