commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [Configuration] Proposals...
Date Sat, 15 Jun 2002 21:28:22 GMT
> From: [] 
> >Please note that Apache Avalon already has a very nice and flexible 
> >Configuration object.
> >Could you let me know how your\'s differs?
> The Avalon Configuration is good. I think that one that is better:
> 1) Is not in Avalon but in commons

This is a stupid requirement, so I will ignore it.  The questions are
purely technical, not political.  Please refrain from making it so.

> 2) Allows for values and attributes at all levels in the tree, like
> mailer=My mailer


The configuration object is hierarchical in nature, so it can represent
XML in its fullest with some minor constraints.  Those constraints are
by design because it is not designed to replace DOM.  Therefore, I can
easily represent information like this:

  <mailer fromAddress=""
  <other name="example">
    <description>No mixed elements, but that isn't too bad</description>

You would get at the information like this:

mailer = config.getChild("mailer").getValue();
fromAddress = config.getChild("mailer").getAttribute("fromAddress");
transportClass =

example = config.getChild("other").getAttribute("name");
description =

It also provides access to type safe primitives.

The Avalon configuration object is pretty flexible.  So please explain
what you mean by "values and attributes at all levels of the tree".

The only limitation on an XML format that it enforces is an HTML like

"this is a <em>mixed</em> value"

You cannot mix a "value" and child components.  You can have attributes
wherever you want.

> 3) relies on the common Transformation/Conversion framework, 
> in some kind of Transformation/Conversion component common 
> for all common components, so that the configurator doesn\'t 
> need to know all ways of transforming String data in the 
> properties into real objects for the app.

That is a tool that can be built on top of the Configuration
object.  You do have direct access to primitives, so that is
a decent thing.

However please differentiate between configuration information
and application objects.  If you want to use a tool to automate
it, go for it.

> 4) Is tied to BeanUtils set/put/add methods, so that indexed 
> properties and dictionary properties could be dynamically configured

Could you explain that a bit more?
What real problem are you trying to solve here?

> 5) Has support for the pool and the factories so that their 
> usage is dynamically controllable from within the properties file.

This is completely orthagonal to a configuration object's
responsibilities.  That is a question of how your software uses
the configuration information.

> 6) Is subsystem based so that the writer of a subsystem 
> defines what kind of data he or she needs for the app to 
> work. The assembler of the whole app doesn\'t need to 
> consider what the subsystems need, they tell the 
> configuration framework what data they need.

The configuration object is just a way to represent that
information.  We have helper classes to load configuration
information and to serialize it.  The configuration object
is just that--a way to represent configuration information
in a neutral way.

It represents hierarchical information, so you have the
benefit of reading in an XML file, and having a whole tree
of the Configuration objects at your disposal.  If you want
to break off a piece of that tree and hand it to a subsystem,
then that is what it does best.

Avalon uses it to read in configuration information for its
containers.  It then breaks the tree down into smaller bits
and passes them to the components.  It's pretty simple, and
surprisingly elegant.

> 7) Is beans based, so that the look of the config bean 
> (holding all objects a subsystem needs to have configured) 
> decides what must go in the config files, at the discretion 
> of the sub system writer.

I disagree here.  Not necessarily a real requirement for
a configuration object.

> 8) Manages a bunch of formats (traditional props, XML) as 
> well as graphic config tools (yes, we need to convince the 
> point-and-click-users as well)

The configuration object is a persistence neutral way of
representing all those bits of information.  It is the
persistence utilities' responsibility to make it become

BTW, XML and props are supported natively.

> 9) Manages reconfiguration, so that the sub system writer 
> doesn\'t have to.

That is a tool that needs to be written, but again, that is
over and above a configuration object.

> Etc.
> I have classes that performs some of this already. I will 
> gladly donate them, but the power lies in the unbundling and 
> integration of factories, transformation, pools etc, in 
> commons as a whole, which is a greater matter.

I propose having a persistence neutral way of representing
the configuration information (Hey one already exists!), and
then tools can be written to use the configuration object
to do all the stuff you propose.

What it seems to me is that you want a configuration SYSTEM,
which is more than what representing configuration information
is about.

What I would like to see is less duplication of effort.

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

View raw message