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