> > >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. > Agreed this is the best way to do this. My worry at this point is how do we do this for external MBean 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]>
