commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Configuration] Proposals...
Date Mon, 17 Jun 2002 14:51:03 GMT
> From: St├ęphane MOR [] 
> >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.

I know the feeling...

The COnfigurationBuilder/ConfigurationSerializer would be able to
read them in.  Perhaps something along the lines of a config tree
like this:

  <entry num="1" name="config" value=""/>

But then we have to consider what is the "1" used for.  In your
example, it looks like an ordinal.  The config builder can safely
drop that field in favor of accessing it like this:

Configuration[] entries = config.getChildren("entry");

for (int I = 0; I < entries.length; I++)
    store (I, entries[I].getAttribute("name"),

However if the number is significant, then the builder would still store

The serializer would worry about the number incrementing.

Granted this also gives you some flexibility in migrating your
config file formats.  Since the configuraiton object only represents
the information that is in the config file, you can use a serializer
that saves it as XML as opposed to a tab delimited format.

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

Sure thing.

>  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() ?)

The config builder/serializer takes care of these details.
It is as predictable as you want it to be.

> Now, for the layout ?

That is decided by the config builder.  You should try to
keep a standard for the layout so that you can interchange
persistence mechanisms as much as possible.

> Would I need to extend DefaultConfigurationBuilder to handle 
> the config 
> file ?

Yes.  I have been wanting to provide some different config
builders, but hadn't the time yet.

> What if another file has another layout ?
> What if I have to deal with 10 files with 10 different layouts ?

Many different file formats can be converged.  I have done
something that will allow anything as a delimiter, supporting
escape characters.  So if your tab delimited file was changed
to "|" (or bar delimited) then you don't have to alter the
builder (just set the delimiter/escape character).

However not all file formats are compatible.

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

Jmeter is using the Avalon jar just for the config package.
The Avalon framework jar is pretty small.

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


Sounds good.  I really would like to see something like a
Configuration Manager for Avalon configuration objects.
I have been intending to write something for a long time
now, but since to date I have been the only one with the
itch to scratch and I haven't had the time it just hasn't
been done yet.

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

View raw message