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]
