commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] New tree package
Date Thu, 29 Dec 2005 07:23:25 GMT
Emmanuel Bourg schrieb:
> Oliver Heger wrote:
>> As I have promised, I plan to add support for XPATH queries to
>> (hierarchical) configurations. In a first step I did some polishing of
>> the Node class used internally by HierarchicalConfiguration; the current
>> way of storing child nodes and attributes made it very difficult to
>> efficiently select nodes based on queries. For this purpose I added a
>> new tree package, which ATM is somewhat experimental.
> Great! I looked quickly at the patch, some thoughts:
> - ConfigurationNode, a shorter name would be better, but I don't have a 
> good alternative. We can't reuse "Node" since it's the name of the inner 
> class in HierarchicalConfiguration. Maybe the refactoring could be 
> pushed further by extracting HierarchicalConfiguration.Node and merging 
> it into the top level default Node implementation. This will break the 
> compatibility, but on the other hand the methods dealing with the nodes 
> are not frequently used by the final users.
Not sure about that. My intension was to keep compatibility - if 
possible. Perhaps we can deprecate some of the old stuff.

> - Attributes: XMLConfiguration is the only hierarchical configuration to 
> expose attributes. What about moving the methods of ConfigurationNode 
> dealing with the attributes in the XMLNode implementation ? Unless an 
> attribute is defined as a child node with a value and no children ?
True, attributes are only used by XMLConfiguration. OTOH some query 
languages like XPATH have special concepts about them. When implementing 
such languages, I assume it will be easier if we don't need to 
distinguish by the node type; so I added the attribute methods to the 

>> Next thing I am going to do is extracting code that interprets property
>> keys from HierarchicalConfiguration.
> Do you plan to depend on an external library like jxpath ? If we could 
> keep it optional that would be nice.
I plan to introduce a concept like an ExpressionEngine (or QueryEngine?) 
that is used by hierarchical configurations. There will be a 
DefaultExpressionEngine that implements the property keys we have now.

If XPATH should be used, a specific XPathExpressionEngine must be set, 
which will depend on a library (probably jxpath - we should eat our own 
dog food ;-) So this new dependency will be completely optional.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message