geronimo-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 Fri, 30 Oct 2009 08:34:59 GMT
2009/10/30 Guillaume Nodet <gnodet@gmail.com>

> There are discussions about implementing rfc 139 inside the Aries
> podling, so maybe it would make sense to discuss that in this context
> too.
>
> From a Karaf pov, I think it would really make sense to add such an
> mbean.  Do you see a single mbean for the extender that would allow
> accessing the BlueprintContext through a tabular data or do you see
> one mbean per BLueprintContext ?  I would lean toward the first
> solution so keep the coarse grained behavior of rfc 139.
>
> Yes, I am suggesting the first approach.
-Rex


> On Fri, Oct 30, 2009 at 06:54, Rex Wang <rwonly@gmail.com> wrote:
> > This topic might be a little bit independent from what we are doing in
> > current osgi integration work. However, I would like to raise such
> > discussion because I believe blueprint will act as an important role in
> our
> > future framework. So, if we wanna leverage blueprint as a common way to
> > construct geronimo plugins and hope use JMX for remote management, we
> > definitely need a set of mbeans to track the blueprint bundles.
> Currently, I
> > am working on this work item.
> >
> > OSGi Alliance is planing to release an enterprise spec which contains rfc
> > 139(mbeans for core framework and 3 compendium services), but there is no
> > mbeans for blueprint. So I think our jobs go ahead of the standard. We
> did a
> > quick look on karaf and spring dm, and did not found them using mbeans to
> > track and manage the state of blueprint. I hope the works we are doing
> are
> > helpful as a complement of rfc 139.
> >
> > OK, although RFC139 says it is not to provide a generic mechanism that be
> > used to expose management of arbitrary OSGi services through JMX, we
> still
> > deside to keep our design consistent with it. That is to leverage the
> > openmbean's open type in the data structure of mbeans' return value, such
> as
> > compositeType, tabularType.. And there is not too much APIs exposed by
> > blueprint, so I think only one Mbean is enough right now.
> >
> > A problem is that how we track the status. In the rfc124 spec, blueprint
> > bundle's status can be identified by listening the events that
> pre-defined.
> > The blueprint extender sends those events to the Event Admin service, but
> in
> > RFC 139 there is no mbeans designed to manage the event admin. So looks
> like
> > we need a mbean provides the APIs to track bluepirnt application and its
> > implementation must also implement the BlueprintListener interface. That
> is
> > what we are thinking currently.
> >
> > Is anybody insteresting on this topic or do you know anythings behind the
> > scenes from Karaf/Springsource that say why they seems not plan to design
> > such mbeans?
> > Any comments is appreciated.
> >
> > Regards
> > -Rex
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>

Mime
View raw message