Rex Wang wrote:
2009/10/30 Guillaume Nodet <[email protected] <mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>> 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
