commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Fiol <antonio.f...@gmail.com>
Subject Re: [configuration]Problems with XMLConfiguration
Date Tue, 07 Sep 2004 19:35:20 GMT
> Regarding hierarchical structures I even wonder if there isn't a way to
> share more code between JNDIConfiguration and
> HierarchicalConfiguration/XMLConfiguration, I feel the tree walking
> logic could be mutualized but I haven't dug this subject yet.

That sounds great! That smells great! Please tell me it is possible.

So far, I'm stuck on two points with JNDI.

1.- Is it possible to have two properties at the same point? How?

I mean: What is the JNDI equivalent for the following XML configuration file?
<conf>
  <propName>A</propName>
  <propName>B</propName>
</conf>

Otherwise, is there a point for getList with JNDI?

2.- I've seen an XML config like:
<conf>
  <struct name="A">
     <prop name="p1">value1</prop>
     <prop name="p2>value2</prop>
  </struct>
  <struct name="B">
     <prop name="p1">value3</prop>
     <prop name="p2>value4</prop>
  </struct>
</conf>

Then, they do things like: getList("struct[@name]")
And they use the index to getList("struct("+i+").prop[@name]")
And they use the index to getString("struct("+i+").prop("+j+")")
And finally, they build a vector of hashtables, or something like that.

Well, something really horrible, IMHO.

I proposed:
<conf>
  <A>
    <p1>value1</p1>
    <p2>value2</p2>
  </A>
... and so on.

This way, I remove attributes, and so I make it more compatible with JNDI.
But then, how can they get the right lists to build their structures?
Before reading the config, they do not know that "A" will be "A" and
"B" will be "B". And there can be any number of them.
Think of a log4j.properties kind of configuration, where one describes
the "available" resources, but resources need to be built in the
beginning so one cannot wait until the name is known.

Any insights?

Yours,

Antonio Fiol

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