Emmanuel Bourg wrote on Tuesday, March 30, 2004 4:44 PM: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.
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
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.
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
