commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From St├ęphane MOR <>
Subject Re: [Configuration] Proposals...
Date Mon, 17 Jun 2002 13:12:43 GMT
Hi Berin,
I am not Ola Berg who you are responding to, but I'm interested by all 
those different
points of view, so ...

>Keep in mind the Configuration abstraction in Avalon has been
>around since 1999.  It is largely unchanged (with the exception
>of the package name) since then.
>Why doom yourselves to repeat the effort?
I promise that is it what I try to avoid ... I've looked at the (very) 
few systems
available (== opensource) that would allow me to do what I need to and none
satisfied me (or I didn't find a way to do what I need with them).

Maybe I need more info/understanding of how other systems work.
You probably can tell me how to do with Avalon.
So, let's take a simple configuration file (let's say I CAN'T change it, 
not the layout at
least). This configuration file would have 3 fields : the line number,
a String field representing, say, the nickname of an object, another 
String field, say,
the classname of an object. This would result as a configuration file 
that looks like :

#LINENUMBER ........ NICKNAME ........ CLASSNAME (the dots stand for tabs)
1 ...... config ......
2 ...... field ......
3 ...... entry ......

This is a very dumb example, but other configuration files could at 
least LOOK the same,
and some of the ones I deal with do.

What would I need to handle this with Avalon ?
How could I access the values it contains ?

 From what I see in Avalon's Configuration API, I would use 
getValueAsInteger() for the first,
and simply getValue() for the others ... This is what in commons' 
Configuration, it's simple
and I understand that. I get I would get the Field's value by a 
getField(String name) equivalent (getChild() ?)

Now, for the layout ?
Would I need to extend DefaultConfigurationBuilder to handle the config 
file ?
What if another file has another layout ?
What if I have to deal with 10 files with 10 different layouts ?

This is a very technical info that I'm missing ... I don't care if the 
package is from this or that other
package, as long as it does what I want it to do ... If I find something 
else that helps me to do it in a
way that is satisfying, no problem, I'll use that. I just didn't find 
that system till now.

If you could tell me technically how I could handle the above file, I 
may simply use Avalon's system
instead of trying to build my own one.
I hope that it is somehow separated from Avalon (because my app doesn't 
want to be component-oriented) ?

>The point is that I think you are going down the path of
>more work than necessary for this.  I haven't needed anything
>more than an object receiving a Configuration object to do
>its work.
I would love to avoid some of the work !
Yep, an object receiving a Configuration is good (at least it's what 
Avalon does).

>If you like a utility, and use it, do you really care where
>it comes from?

>I would like to see how your quite complex config system would
>be better than the current simplistic approach used in Avalon.
>Simplicity makes things easier to use and understand.  Complexity
Agreed at 100%.
My system (I don't know about Ola's) uses simple beans and Betwixt to 
map the
descriptor to the Object Model. I think most people can cope with that.
The XML descriptor (not the configuration, the description of the 
uses simple structures, a la Ant, and no namespace, but properties (like 
and that's about all. The reading / writing of the actual config files 
is meant to be
hidden from the user.

>I am trying to trace a bug in Visual C++ STL which, purely syntactically
>speaking, should work.  The problem is all the black magic that goes
>on under the scenes that is causing an Access Violation Exception
>where one should never exist.
>I have refactored a number of systems that where too complex when
>they started out, forcing the user to know too much.  I like simplicity
>because I don't have to waste 12 hours (my last Friday) trying to
>chase down a bug that by all other means should not exist.
This is why I want to avoid letting the user to define his own elements, 
field types,
etc. The core will be the simplest possible (I don't want to get lost 
myself !).

>I should not have to debug Microsoft code to fix my system.  I have a
>feeling that where you are starting will force users to debug commons
>code to fix their system when by all other means it should work.
>It's a slippery slope.  Perhaps its uncertainty on my part, I haven't
>seen your work so I can't say anything one way or the other about it.
>My humble suggestion to you is to start simple, and add on from there.
I start simple, and hopefully will stay simple. I just hate when I have 
to spend hours
understanding things that should be simple. My ideal goal is to have 
people understand
it just by reading the XML descriptor.


Do You Yahoo!?
Get your free address at

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

View raw message