2009/11/19 Siqi Du <[email protected]> > 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？ > There is no need to design such 2 mbeans, because you can not make any operation on an extender. The intent here is to track the blueprint bundles state. Please take the FrameworkMBean and BundleStateMBean as an example. Thanks :-) -Rex
> > > 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. > > >
