>Well the way I see it is that there is 3 types of information that each Block
>may want to expose to management.
>
>* Firstly there is the standard configuration info. Ideally an XSchema could
>be exposed and managed by JMX via some method. The JMX would then validate
>the XML and stuff it back into ConfigurationRepository as necessary. Other
>standard configuration stuff would include the location to which data is
>logged and possibly other stuff.
>
I'm not sure I follow you 100% here:
Should the individual blocks read their own config file(s) directly or
should they be initialized with config data
by a 'BlockManager'? Hence, the BlockManager is between a block and the
block's specific config
files, the block itself never reads its own config files directly(?)
>* Secondly there is extra interfaces that a Block may *choose* to expose to
>JMX. Not all services need to be or should be automatically exposed. IMO it
>should be the block that choose which services it wants to expose via JMX.
>These could either be directly implemented by the Block or implemented by
>supporting classes.
>
Yes I agree completely to the above. The exposed operations should be in
the xinfo(?) in a form like (I have
used as an example the integration of Tomat4 or some other Webapp
container):
<operations>
<operation Name="addWebApp" Description="Add a Web Application
to a virtual host">
<parameter Name="webappname" Description="Name of the
WebApp">myWebapp</parameter>
<parameter Name="vhost" Description="Website (VirtualHost) Name
for the WebApp">host.com</parameter>
</operation>
<operation Name="delWebApp" Description="Delete a Web
Application from a virtual host">
<parameter Name="webappname" Description="Name of the WebApp to
delete">myWebapp</parameter>
<parameter Name="vhost" Description="Website (VirtualHost) Name
to delete the WebApp from">host.com</parameter>
</operation>
</operations>
Now, you are probably wondering why the extra attributes? This is for
the management interface primarly,
whatever it may be, but the Name and Description map nicely to
MBeanParameterInfo and MBeanOperationInfo fields ;)
Hence, we can be 100% JMX by constructing the BlockDynamicMBean from two
parts: one part the actual block interface(impl)
the second part the info stored in the xinfo, which of course the
BlockDynamicMBean would read to construct the required
objects properly. Unless of course the actual implementation of the
MBean does this (putting in the op names/desc/etc)....
>
>* Thirdly there is the generic management part (ie startup and shutdown of
>blocks). However as this ought to be controlled by the Application as a whole
>this should probably be exposed via an ApplicationMBean rather than a
>BlockMBean
>
What you are saying is that we should have two different types of Blocks
- one that is an ApplicationBlock
and another which is... well a Block. Then from the above point we
would have ApplicationBlockDynamicMBean
and BlockDynamicMBean. BlockDynamicMBean is extended by
ApplicationBlockDynamicMBean but implements
a runnable type interface.
cheers
Pratik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
