geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Mbeans for Blueprint
Date Fri, 30 Oct 2009 05:54:22 GMT
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.


View raw message