commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From St├ęphane MOR <stephane_lis...@yahoo.fr>
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 ...... org.foo.bar.Configuration
2 ...... field ...... org.foo.bar.Field
3 ...... entry ...... org.foo.bar.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?
>
No.

>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
>kills.
>
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 
configuration)
uses simple structures, a la Ant, and no namespace, but properties (like 
${foo.bar}),
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.

Thanks,
St├ęphane


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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


Mime
View raw message