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 Sat, 31 Oct 2009 11:16:44 GMT
2009/10/30 Guillaume Nodet <gnodet@gmail.com>

> I would think each blueprint bundle managed by this extender would be
> an entry in the tabular data and contain several informations,
> including the state and last event(s), so that the error would be
> available (or maybe it should be available directly).
>
> Agree. Then the implement of such mbean have to be a BlueprintListener so
that it can receive the last event of each blueprint bundle?

-Rex

>
> On Fri, Oct 30, 2009 at 10:41, Rick McGuire <rickmcg@gmail.com> wrote:
> > Rex Wang wrote:
> >>
> >>
> >> 2009/10/30 Guillaume Nodet <gnodet@gmail.com <mailto: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.
> >
> > I think it would also be very valuable to be able to retrieve any
> blueprint
> > deployment failures so that
> > errors can be diagnosed.
> > Rick
> >>
> >> -Rex
> >>
> >>    On Fri, Oct 30, 2009 at 06:54, Rex Wang <rwonly@gmail.com
> >>    <mailto: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
> >>
> >>
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>

Mime
View raw message