aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: Mbeans for Blueprint
Date Thu, 19 Nov 2009 09:06:54 GMT
2009/11/19 Siqi Du <siqi.du@gmail.com>

> 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 <alantkeane@gmail.com>
> >
> >> 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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message