I also feel it is not very graceful to use containerServiceId every time. In common cases there are several container services and a single extender service. Maybe it is better to distinguish the mbean for blueprint extender from the mbean for a blueprint bundle/container？
> 2009/11/19 Alan Keane <[email protected]> > >> Hi, >> >> The interfaces defined look good to me both in terms of usefulness and >> consistency with RFC-139. >> The BlueprintMetadataMBean supports querying of the metadata based on >> containerServiceId and componentId so I don't think >> we would have any need for a single MBean for each BlueprintContainer >> service. >> If required it would be relatively straightforward to extend the JMXAgent >> to >> discover and manage the lifecycle of these or >> other additional MBeans for compendium services. >> > Yes. I agree. > I see the RI using an acivator to register the MBeans to mbean servers. I > don't very like such implement. If your jmx agent can be published as a > service, the bundle of blueprint mbean implement can leverage such service > to register its mbean to all the servers. That is, the new mbean bundles > don't need to implement another jmx agent itself. On the other hand, as you > state above, including the blueprint mbean implement in our Aries' 139 > imlpement bundle and extend the JMX agent is a good approach. >
