Agreed this is the best way to do this. My worry at this point is how do we do this for external MBean
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.
services we would like to wrap. I suppose this would be very dependant on the 3rd party MBean, as
no one really follows a convention (or 'pattern' LOL).
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
The above seems sensible to me.
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.But do we want to make an interface to the block for start/stop/etc so that we have a uniform way for the
application to start/stop blocks? I apologize in advance if this an ignorant question, as I can't get to the
Avalon website to check the current block interface... connection problems today (on my end, "Â$%^&* ISP).
cheers Pratik
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
