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