avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mircea Toma" <mircea.t...@calgary.qcdata.com>
Subject Re: Configuration management
Date Wed, 12 Sep 2001 17:16:15 GMT

----- Original Message -----
From: "Berin Loritsch" <bloritsch@apache.org>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Sent: Wednesday, September 12, 2001 10:59 AM
Subject: Re: Configuration management


> Mircea Toma wrote:
> >
> > Hi,
> >
> > ----- Original Message -----
> > From: "Berin Loritsch" <bloritsch@apache.org>
> > To: "Avalon Development" <avalon-dev@jakarta.apache.org>
> > Sent: Wednesday, September 12, 2001 6:56 AM
> > Subject: Re: Configuration management
> >
> > > Peter Donald wrote:
> > > >
> > > > On Wed, 12 Sep 2001 09:02, Mircea Toma wrote:
> > > > > Hi,
> > > > >
> > > > > To change the Configuration at runtime we need a
> > ModifiableConfiguration (I
> > > > > know that there were some discussions about this) in this way I
can
> > have
> > > > > the management written against a interface not a class. I guess
the
> > > > > interface is straight forward since this functionality is
implemented
> > by
> > > > > the
> > > > > DefaultConfiguration:
> > > >
> > > > Sounds good to me.
> > >
> > > I'm still not crazy about it.  There have to be some tight controls
over
> > who
> > > can write to it.  The best I can come up with is equivalent to the
> > java.util.Collections
> > > class that returns an unmodifiable collection.  To that end, we need a
> > Configuration
> > > that encapsulates other Configuration objects and enforces the
read-only
> > approach.
> > >
> > > The UnmodifiableConfiguration will have a constructor that accepts a
> > Configuration
> > > object.  That object and all child objects will be protected from
being >
> > modified.
> >
> > How about having that constructor for the DefaultConfiguration?
>
> It is possible.  The UnmodifiableConfiguration approach does not provide
any
> methods whatsoever for altering the contents of the Configuration object,
> which IMO is better.
>
> Remember that there are two Configurable interfaces.  The default
Configurable
> which marks components that are configured once and the Reconfigurable
interface
> that marks components that can be configured multiple times.  I am not
sure how
> you plan on having the configurations change.
>
> Is it part of the normal opperations for some components to alter their
own
> configuration?

No, not at all!

> Or are you planning on having an outside entity alter the configuration
> file and have the server detect the changes?
>
> If the latter is the case, Excalibur's resource monitoring code is for
you.  It will
> notify you when the configuration file has been altered, so you can
reconfigure
> all your components.

This is taken from one of my previous email on this subject:

"The "configuration" management can be done by
changing the configuration trees stored in the ConfigurationRepository, the
Block-s that
will implement Reconfigurable interface will receive automatically the new
configuration (assuming that the "monitor" package will be used)."

Mircea

>
> If the former is the case, this is akin to machine language programs that
alter their
> own code to squeeze out a few more bytes.  It just opens up so many
issues.
>
> > > I agree.  We should use Schema to describe the XML as much as
possible.
> > Please
> > > note, that I have started to write a Class that will serialize a
> > Configuration
> > > object over a stream.
> >
> > Cool, I guess this is the complement of SAXConfigurationHandler?!
>
> More a compliment to the DefaultConfigurationBuilder, but effectively yes.
> This way, your configuration objects can be persisted no matter where you
> want them to persist.  And they should be able to read what they wrote.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message