----- Original Message -----
From: "Berin Loritsch" <[EMAIL PROTECTED]>
To: "Avalon Development" <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 10:59 AM
Subject: Re: Configuration management
> Mircea Toma wrote:
> >
> > Hi,
> >
> > ----- Original Message -----
> > From: "Berin Loritsch" <[EMAIL PROTECTED]>
> > To: "Avalon Development" <[EMAIL PROTECTED]>
> > 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
