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]
