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. On Fri, Oct 30, 2009 at 06:54, Rex Wang <[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
