commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [configuration] Flattening trees
Date Tue, 30 Mar 2004 15:07:29 GMT
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:
> 
> <a>
>    <b>
>      <c>value1</c>
>    </b>
>    <b.c>value2</b.c>
> </a>
> 
> 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).

Regards,
Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message