commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [Configuration] Proposals ...
Date Mon, 17 Jun 2002 12:29:27 GMT
> From: St├ęphane MOR [mailto:stephane_listes@yahoo.fr] 
> >
> >Please note that Apache Avalon already has a very nice and flexible 
> >Configuration object.  The interface for it is located here:
> >
> >http://cvs.apache.org/viewcvs/jakarta-avalon/src/java/org/apa
> che/avalon
> >/
> >framework/configuration/Configuration.java?rev=HEAD&content-t
> ype=text/vn
> >d.viewcvs-markup
> >
> >
> >Could you let me know how your's differs?
> >
> Hi Berin,
> 
> I looked at Avalon's Configuration package a while ago when I 
> used Avalon. It is nice, but I stopped using it when I 
> stopped using Avalon (new 
> projects didn't need/fit into it).
> 
> The main difference is in the goal : I need to be able to use legacy 
> configuration files, used by other applications,
> as well as properties files. This includes being able to treat files 
> such as :
> 
> ------------------- samples -----------------
> #FIELD1    FIELD2    FIELD3
> leonard        cohen        singer
> luc                besson      director
> 
> or :
> 
> section1:
>     test=value
>     foo=bar
> 
> section2: ...
> ------------------------------------------------
> 
> So, technically, the second difference raises : I don't want 
> to use the 
> XML file as the proper configuration, as in Avalon
> (tell me if I'm wrong), such as :
> 
> ------------------------------------
> <fields>
>   <fieldA>value1</fieldA>
>   <foo>bar</foo>
> </fields>
> ------------------------------------
> 
> but I want to build an XML descriptor of a configuration 
> file. (A sort 
> of configuration's configuration ...) more like the
> commons Configuration package. With this configuration file you would 
> then be able to read (AND WRITE, which is another difference) 
> configuration files for your applications, which may be every 
> application (in my case, Samba, FreeSwan, Shorewall, my 
> Turbine app, etc.).

The role of persistence in Avalon is through helper classes.
We have a ConfigurationBuilder to build the files (currently
through XML), and a ConfigurationSerializer to write the
files.


> The XML descriptor is meant to be constant (well, adaptable when 
> needed), so that it can be parsed easily and confronted to a 
> DTD and/or a schema. Avalon configurations can't be natively 
> confronted to a DTD as 
> the structure is very free and one can add whatever field he wants.
> 
> I hope that those short explanations shed some light ...



> 
> I know that I have some very specific needs, tied to my applications' 
> goals. This is why I asked if there is an actual interest in 
> such a package. Though, many times I feel that I cross other 
> projects needs (commons' 
> Configuration at least), so I wondered if that could be 
> thought of with the people working on these projects, and maybe mixed.
> 
> I saw that the commons Configuration package was attempting 
> to build a 
> framework to deal with XML config files. As using XML config 
> files is a growing practice (though I never encountered any in the 
> applications config files I has to manage), I think that such 
> a framework could help dealing with them.
> 
> >I would like to reduce duplication amicably if at all possible.
> >
> Agreed at 200% !
> This was actually the whole point of my message !!


Thank you for the backgrounder.  The Avalon team is entering design
stage for the fifth generation of the tool.  We do want to work
with commons if possible on many fronts.  (As a teaser, we are
seriously considering using commons logging in A5).  What I want
to know is how commons config works with avalon config.

If possible, it would be best for the two to share a common
representation of configuration information.

Avalon has Configuration and Parameters--which represent two different
types of information.

Configuration is a tree-like structure.  You can enforce a schema on it,
as it does now support namespaces.  (It keeps reference to the shortname
only for the sake of serialization).  We have always wanted to enforce
some sort of validation scheme on top of the representation.

The Parameters object is much like the Properties object, with the
addition
that you can convert a Configuration subtree to a Parameters object.
(Note,
you can also convert a Properties object to a Parameters object).

Again it is subject to Builders and Serializers ATM to persist the data.


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