2009/10/30 Guillaume Nodet <[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. -Rex
> 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 >
