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