You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ola Berg <ol...@arkitema.se> on 2002/06/15 22:14:06 UTC
Re: [Configuration] Proposals...
>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
2) Allows for values and attributes at all levels in the tree, like
mailer=My mailer
mailer.fromAdress=ola.berg@arkitema.se
mailer.transportClass=nu.viggo.net.smtp.SMTPTransport
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.
4) Is tied to BeanUtils set/put/add methods, so that indexed properties and dictionary properties could be dynamically configured
5) Has support for the pool and the factories so that their usage is dynamically controllable from within the properties file.
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.
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.
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)
9) Manages reconfiguration, so that the sub system writer doesn\'t have to.
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.
/O
--------------------
ola.berg@arkitema.se
0733 - 99 99 17
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Configuration] Proposals...
Posted by Berin Loritsch <bl...@apache.org>.
> From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
>
> >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
> mailer.fromAdress=ola.berg@arkitema.se
> mailer.transportClass=nu.viggo.net.smtp.SMTPTransport
?
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:
<root>
<mailer fromAddress="ola.berg@arkitema.se"
transportClass="nu.viggo.net.smtp.SMTPTransport">My
mailer</mailer>
<other name="example">
<description>No mixed elements, but that isn't too bad</description>
</other>
</root>
You would get at the information like this:
mailer = config.getChild("mailer").getValue();
fromAddress = config.getChild("mailer").getAttribute("fromAddress");
transportClass =
config.getChild("mailer").getAttribute("transportClass",
"org.apache.transport.DefaultSMTPTransport");
example = config.getChild("other").getAttribute("name");
description =
config.getChild("other").getChild("description").getValue();
It also provides access to type safe primitives.
The Avalon configuration object is pretty flexible. So please explain
by
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
config:
"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
XML/props/etc.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Configuration] Proposals...
Posted by Paulo Gaspar <pa...@krankikom.de>.
It looks like we completely agree then.
=:o)
Have fun,
Paulo
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Monday, June 17, 2002 7:41 AM
>
>
> On Mon, 17 Jun 2002, Paulo Gaspar wrote:
>
> > > Please note there are 2 important APIs you should look at - JMX and
> > > java preferences.
> >
> > Yeah... although I am not impressed about the Java Preferences thing.
> > Is it just me or are SUN APIs going down on quality lately?
>
> I agree java preferences is not the best - and the fact they tied it
> to JDK1.4 makes it unacceptable ( for me ).
>
> That's why I think we need some common component that provides the same
> functionality, maybe with a better interface, but capable to wrap
> JDK1.4 prefs if 1.4 is detected ( like commons-logging does for logging ).
>
> Like it or not, registry and directory based configuration is
> valid and widely used, and IMHO has few benefits. JNDI is far too
> complex for that.
>
>
> > > My view on configuration is that JMX should be used as the main
> > > interface for the configurable components, and something similar
> > > with java preferences ( but useable in JDK < 1.4 ) for storing/reading
> > > the data.
> >
> > If you turn that "should" from "...JMX should be used..." into a
> > "could", I would agree.
> >
> > I would hate having to use JMX to configure some of my lighter
> > stuff.
>
> I agree, 'could' is the word.
>
> Actually, at least in a dynamic mbean solution there is no JMX
> required - all you do is use plain beans, with the normal patterns,
> and you can use an introspection based bean to jmx-enable the
> component if you want to. Modeler is another choice where again
> you just write beans, without any deps on jmx.
>
> Costin
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Configuration] Proposals...
Posted by co...@covalent.net.
On Mon, 17 Jun 2002, Paulo Gaspar wrote:
> > Please note there are 2 important APIs you should look at - JMX and
> > java preferences.
>
> Yeah... although I am not impressed about the Java Preferences thing.
> Is it just me or are SUN APIs going down on quality lately?
I agree java preferences is not the best - and the fact they tied it
to JDK1.4 makes it unacceptable ( for me ).
That's why I think we need some common component that provides the same
functionality, maybe with a better interface, but capable to wrap
JDK1.4 prefs if 1.4 is detected ( like commons-logging does for logging ).
Like it or not, registry and directory based configuration is
valid and widely used, and IMHO has few benefits. JNDI is far too
complex for that.
> > My view on configuration is that JMX should be used as the main
> > interface for the configurable components, and something similar
> > with java preferences ( but useable in JDK < 1.4 ) for storing/reading
> > the data.
>
> If you turn that "should" from "...JMX should be used..." into a
> "could", I would agree.
>
> I would hate having to use JMX to configure some of my lighter
> stuff.
I agree, 'could' is the word.
Actually, at least in a dynamic mbean solution there is no JMX
required - all you do is use plain beans, with the normal patterns,
and you can use an introspection based bean to jmx-enable the
component if you want to. Modeler is another choice where again
you just write beans, without any deps on jmx.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Configuration] Proposals...
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Costin,
> Please note there are 2 important APIs you should look at - JMX and
> java preferences.
Yeah... although I am not impressed about the Java Preferences thing.
Is it just me or are SUN APIs going down on quality lately?
> My view on configuration is that JMX should be used as the main
> interface for the configurable components, and something similar
> with java preferences ( but useable in JDK < 1.4 ) for storing/reading
> the data.
If you turn that "should" from "...JMX should be used..." into a
"could", I would agree.
I would hate having to use JMX to configure some of my lighter
stuff.
=:o/
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Sunday, June 16, 2002 9:32 AM
> To: Jakarta Commons Developers List; Ola Berg
> Subject: Re: [Configuration] Proposals...
>
>
> Please note there are 2 important APIs you should look at - JMX and
> java preferences.
>
> My view on configuration is that JMX should be used as the main
> interface for the configurable components, and something similar
> with java preferences ( but useable in JDK < 1.4 ) for storing/reading
> the data.
>
> Of course, there are other solutions and APIs - and each has
> its benefits.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Configuration] Proposals...
Posted by co...@covalent.net.
Please note there are 2 important APIs you should look at - JMX and
java preferences.
My view on configuration is that JMX should be used as the main
interface for the configurable components, and something similar
with java preferences ( but useable in JDK < 1.4 ) for storing/reading
the data.
Of course, there are other solutions and APIs - and each has
its benefits.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>