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? 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.
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]
