On Sat, 17 Nov 2001 00:06, Pratik Patel wrote:
> >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(?)
yep - you got that right.
The Container (ie what you call BlockManager) manages the configuration and
passes it to blocks. It would also be the ones who woul d have to construct
the MBean that managed this portion of block interface.
> >* 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)....
Not sure where the description of the manageable service interface would go.
I may be inclined to do something like
Block X supports XMBean service. (Theoretically multiple blocks could
actually support the same management interface). So it may be a good idea to
put the management support info (like the Descriptions etc) into another file
that is same name as
SO we would end up with something like
com/biz/blocks/MyBlock.class
com/biz/blocks/MyBlock.xinfo
com/biz/services/MyService.class
com/biz/services/MyServiceMBean.class
com/biz/services/MyServiceMBean.xml
and it would be "com/biz/services/MyServiceMBean.xml" that described the
MBean in all its glory. That way if another block implemented that service it
would automatically inherit all that management metadata.
> >* 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.
Not really. What I am saying is that currently the Application is responsible
for deciding when Blocks will be started or shutdown or whatever. This is
required because there may be interdependencies between blocks and so forth.
So there is no way for a Block to shut itself down, what you really need to
do is ask the application to shutdown the Block and it will take care of
making sure it shutsdown according to the dependency rules etc.
--
Cheers,
Pete
----------------------------------------------------
"The only way to discover the limits of the possible
is to go beyond them into the impossible."
-Arthur C. Clarke
----------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
