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