Hi, ----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]> To: "Avalon Development" <[email protected]> Sent: Tuesday, September 11, 2001 10:18 PM Subject: Re: Configuration management
> 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. > > > The next issue on *the list* is that I'm not sure how should I implement > > the configuration management, until now I have two solutions: > > > > 1) Have a Dynamic that wraps each Configuration object and makes it > > available for management. For a Configuration object the MBean would have > > actions and attributes like: > > > > Configuration: > > -------------- > > <repository > > class="org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Obj > >e ct_Repository"> > > <protocols> > > <protocol>file</protocol> > > </protocols> > > <types> > > <type>OBJECT</type> > > </types> > > <models> > > <model>SYNCHRONOUS</model> > > <model>ASYNCHRONOUS</model> > > <model>CACHE</model> > > </models> > > </repository> > > --------------- > > > > *MBean --------- > > Avalon:block=objectstorage,entry=repositories,entry=repository > > > > *attributes ---- > > > > Class = > > "org.apache.avalon.cornerstone.blocks.masterstore.File_Persistent_Object_Re > >p ository" > > Value = "" > > > > Children > > > > Avalon:block=objectstorage,entry=repositories,entry=repository,entry=protoc > >o ls > > Avalon:block=objectstorage,entry=repositories,entry=repository,entry=types > > > > Avalon:block=objectstorage,entry=repositories,entry=repository,entry=models > > > > *actions ------- > > > > addChild ($name) > > removeChild ($name) > > setAttribute ($name, $value) > > --------------- > > > > This solution is very verbose and pretty difficult to use but allows > > maximum of flexibility. Also, forces you to put your values in the > > attributes in order to facilitate the management. > > > > 2) Second solution would be to use XPath to manage (set/get/add/remove) > > your configuration. This is prone to errors and its difficult to use from > > an administrator perspective. > > > > > > I prefer the first solution but I'm not convinced that it's the best > > approach. > > Any thoughts are very welcomed! > > 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. > > So in the BlockInfo file you would have something like > > <complexType name="repository"> > <attribute name="class" type="xsd:string"/> > <element name="protocols"/> > <element name="types"/> > <element name="models"/> > </complexType> > > <complexType name="protocols"> > <element name="protocol" minOccurs="1" > maxOccurs="unbounded" type="xsd:string" /> > </element> > </complexType> > > <complexType name="types"> > <element name="type" minOccurs="1" > maxOccurs="unbounded" type="xsd:string" /> > </element> > </complexType> > > <complexType name="models"> > <element name="model" minOccurs="1" > maxOccurs="unbounded" type="xsd:string" /> > </element> > </complexType> > > and you would use that to build the real configuration data. However doing > that requires a massive amount of work and you would probably want to > integrate with one of the existing opensource XML editors (merlot comes to > mind). Or Castor?! They have (exolab.org) a schema to java class compiler, class that will do the validation. The problem is you need access to a compiler at runtime which I think is not the best choice! > > 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. Ok, I get the idea! Mircea > > -- > Cheers, > > Pete > > ------------------------------------------------ > "No. Try not. Do. Or do not. There is no try." > -- Yoda > ------------------------------------------------ > > --------------------------------------------------------------------- > 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]
