commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <sma...@lfjr.net>
Subject Re: [configuration] Any reason why JNDIConfiguration is readonly?
Date Wed, 27 Oct 2004 17:14:53 GMT
Oliver Heger wrote:
> Hmm, navigating through a tree based on a configuration key, creating 
> missing nodes if necessary and finally storing the value...
> 
> Similar code is contained in HierarchicalConfiguration and I suppose in 
> XMLConfiguration, too, to update the internally used DOM tree. I wonder 
> if this could be generalized.

I've been pondering the same thing for quite some time too. I started 
working on a WindowsConfiguration wrapping the windows registry and I'm 
reimplementing the same logic found in the other hierarchical 
configurations. And we will have the same issue if we write a 
LDAPConfiguration.

I tried a quick refactoring of JNDIConfiguration to test this idea, this 
is a rough design, let me know what do you think of it :

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

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

- 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'm attaching the resulting classes, the test cases still pass. I 
started looking at XMLConfiguration but it's a bit more complex.

Emmanuel Bourg

Mime
View raw message