commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Oliver Heger)
Subject Re: [configuration] Flattening trees
Date Tue, 30 Mar 2004 19:25:10 GMT
Jörg Schaible wrote:

>Emmanuel Bourg wrote on Tuesday, March 30, 2004 4:44 PM:
>>Hi, last week I started playing with the Preferences API and
>>a Windows
>>configuration manipulating the registry through JNI. I had not
>>experimented with hierarchical configurations before, this
>>led me to a
>>dumb question : what are we supposed to do when a key
>>contains a dot ?
>>Should we search the value in the sub nodes or get the first property
>>in the current node matching the key ? This issue can be
>>illustrated with
>>the following XML configuration:
>>   <b>
>>     <c>value1</c>
>>   </b>
>>   <b.c>value2</b.c>
>>What's the key "a.b.c" supposed to return ? "value1" ? "value2" ? Or
>>an array with both ?
>>A lot of configurations have a hierarchical structure : LDAP,
>>JNDI, the
>>windows registry, INI files (a tree a depth 1), XML files, the Avalon
>>configuration API, the JDK 1.4 Preferences API. That makes me
>>wonder if
>>we aren't on the wrong track for a generic configuration API,
>>[configuration] is Properties centric for historical reasons,
>>should we
>>keep trying to flatten hierarchical structures and make them
>>look like a
>>.properties file ? Should we change the Configuration interface to
>>support hierarchical structures directly (and turn
>>PropertiesConfiguration into a tree) ?
>To clean-up the resurrected HierarchicalConfiguration problem, you will have to do this
anyway. And IMHO you're right and I already mensioned that e.g. JDNI's nature *is* hierarchical.
Even the java properties are. The flat structure is just a special case of a more generic
hierarchical structure. The flat accessor "a.b.c" is a shortcut for "a(0).b(0).c(0)".
>>Should we support both
>>separately with an XPath like syntax to unify the keys ?
>Definately, but post 1.0. I think you will be able to remove a lot of code with a real
generic solution. For 1.0 we will have to modify the Configuration interface at least in a
way, we can solve the problem with HierarchicalConfiguration and Oliver had a solution for
this (making Configuration hierarchical arware).
Unfortunately I won't have time prior to Thursday evening. Can you tell 
me which unit tests are failing? If it's only the test for 
ConfigurationXMLDocument, I would suggest to drop this class in the 1.0 
release and add it later again (I think it is unlikely that this class 
is already used; it was lost after the move from sandbox and nobody 
noticed). Other tests should not fail because they still worked after 
the SubConfiguration refactoring.

If we start thinking about more support for hierarchical configurations 
(an approach I really welcome), I now don't want to come up with a quick 
solution for the actual problem. It would be much better to do it right 
in the next release.


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

View raw message