geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Mbeans for Blueprint
Date Fri, 30 Oct 2009 09:41:58 GMT
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
>
>


Mime
View raw message