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?
>
> This allows a parent Component to retain the original modifiable
Configuration
> object--but enforces the contract of an unmodifiable Configuration object
being
> passed to Configurable components.
>
>
> > I am not sure - neither sounds ideal IMHO. I think it would be best to
> > experiment and see what works and what doesn't. The question that is
most
> > difficult would be how to manage configuration items that have the same
name
> > - ie
> >
> > <model>SYNCHRONOUS</model>
> > <model>ASYNCHRONOUS</model>
> > <model>CACHE</model>
> >
> > Because JMX only does flat management. The second approach could handle
it
> > but the first one has a little difficulty I think.
> >
> > Ideally I would like the configuration for each block to be defined
using
> > XSchema. The schema would be defined inside the BlockInfo (.xinfo) file
and
> > the management scheme would take this combined with instance data to
> > configure it.
>
> 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?!
Mircea
>
> > I guess that may be the eventual goal but for now it is probably best to
just
> > get something up and running and worry about all these details after
there is
> > a prototype in which we can test different ideas.
>
> The idea is to be forward thinking enough to work toward a goal, but
realistic
> enough to get something working (hopefully that can be used toward the end
goal).
>
> ---------------------------------------------------------------------
> 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]
