avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mircea Toma" <mircea.t...@calgary.qcdata.com>
Subject Re: Configuration management
Date Wed, 12 Sep 2001 16:52:26 GMT
Hi,

----- Original Message -----
From: "Peter Donald" <donaldp@apache.org>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message