commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Any reason why JNDIConfiguration is readonly?
Date Thu, 28 Oct 2004 10:07:05 GMT
I had a short glance at your code (not much time ATM). This seems to be 
similar to my own ideas. Comments inline.

Emmanuel Bourg wrote:
> - a ConfigurationNode interface is introduced, it's an abstract node 
> with basic navigation methods like getElements(), createNode(), 
> getName(). Its implementations will wrap a real node, that's a JNDI 
> Context or a DOM Element for example.
If this ConfigurationNode interface was more powerful, it would support 
generalized update methods (like setProperty(), addProperty()), too. I 
attach my version from my hierarchical design, which has some more 
methods. The methods dealing with attributes are a bit XML specific, but 
I think it can't be wrong to use XML as a model for a generic design. So 
the features of this format can be fully supported and other 
configuration sources that have no attributes can provide dummy 

> - JNDIConfiguration implements a TreeConfiguration interface. This 
> interface exposes the getRootNode() method returning the root 
> ConfigurationNode. We may put in this interface some methods defining 
> the variations of behaviour between the hierarchical configurations 
> (supportsXXX():boolean). For example with an XMLConfiguration, several 
> child nodes can have the same name, this is not true for 
> JNDIConfiguration or WindowsConfiguration, that means the search 
> algorithm is slightly different.
I think a generic search algorithm should be implemented to deal with 
multiple occurences of child nodes. I don't like the idea of having 
if-clauses based on supportsXXX() flags. If a configuration source is 
restricted in this area, the specific implementation of the addChild() 
method could ensure that no douplicated entries are created.

The code in HierarchicalConfiguration could serve as an example for both 
the search and the add/update algorithm. With a generic node interface 
that also provides a method for creating new child nodes this code can 
be made generic.

One more point: Should we have a TreeConfiguration interface or add the 
few additional methods to Configuration? I think the major part of 
configuration sources will be hierarchical and the other ones can be 
seen as hierarchical structures with only one layer. If all 
Configuration classes provided a hierarchical view, there would be no 
need to make distinctions later when implementing features that make use 
of that (e.g. enhanced XML processing).

> - JNDIConfiguration has a private implementation of ConfigurationNode, 
> that's JNDIConfigurationNode.
> - the search methods of JNDIConfiguration have been moved to 
> TreeConfigurationUtils and now use the ConfigurationNode instead of the 
> JNDI context.
> - JNDIConfiguration delegates to TreeConfigurationUtils its 
> implementations for getKeys and isEmpty.
I think it makes sense to have such a class like TreeConfigurationUtils. 
An alternative would be to create a base class 
AbstractTreeConfiguration, but the approach with the utility class is 
probably more flexible.

> I'm attaching the resulting classes, the test cases still pass. I 
> started looking at XMLConfiguration but it's a bit more complex.
> Emmanuel Bourg


View raw message