Well the way I see it is that there is 3 types of information that each Block may want to expose to management.I'm not sure I follow you 100% here:
* 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.
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)....
What you are saying is that we should have two different types of Blocks - one that is an ApplicationBlock
* 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
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]>
