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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
