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]Problems with XMLConfiguration
Date Wed, 08 Sep 2004 11:36:37 GMT
Antonio Fiol wrote:

> So far, I'm stuck on two points with JNDI.
> 
> 1.- Is it possible to have two properties at the same point? How?

I don't think it's possible.

> Otherwise, is there a point for getList with JNDI?

A List could be directly stored in the repository.


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

Parsing the keys of the "conf" subset could be a solution but it's still 
complicated. This may be easier once we refactor the code for 
hierarchical configurations around the version 2.0.

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

I'm not convinced [configuration] is the right tool for complex 
configurations, I tend to prefer [digester] in these cases.

Emmanuel Bourg

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