You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rex Wang <rw...@gmail.com> on 2009/10/30 06:54:22 UTC
Mbeans for Blueprint
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
Re: Mbeans for Blueprint
Posted by Rex Wang <rw...@gmail.com>.
Thanks Kevan! Looks like there was some problems on my windows.. Now I get
it work.
-Rex
2009/11/10 Kevan Miller <ke...@gmail.com>
>
> On Nov 10, 2009, at 2:23 AM, Rex Wang wrote:
>
> Hi dear all,
>> The BlueprintMBean design has finished. I'd like to put the api codes in
>> sandbox and request review comments, but seems I can not create a folder for
>> myself in the sandbox? How to get that?
>>
>
> Following works just fine for me... Can you give it a try and give specific
> error that you're getting...
>
> $ mkdir foo
> $ svn add foo
> A foo
> $ svn ci --message "test directory create" foo
> Adding foo
>
> Committed revision 834454.
> $
>
> Also, unless I'm being really unresponsive, would prefer not to be directly
> cc:ed. Otherwise, mail sorting and reply-to may not work as normal...
>
> --kevan
>
Re: Mbeans for Blueprint
Posted by Kevan Miller <ke...@gmail.com>.
On Nov 10, 2009, at 2:23 AM, Rex Wang wrote:
> Hi dear all,
> The BlueprintMBean design has finished. I'd like to put the api
> codes in sandbox and request review comments, but seems I can not
> create a folder for myself in the sandbox? How to get that?
Following works just fine for me... Can you give it a try and give
specific error that you're getting...
$ mkdir foo
$ svn add foo
A foo
$ svn ci --message "test directory create" foo
Adding foo
Committed revision 834454.
$
Also, unless I'm being really unresponsive, would prefer not to be
directly cc:ed. Otherwise, mail sorting and reply-to may not work as
normal...
--kevan
Re: Mbeans for Blueprint
Posted by Kevan Miller <ke...@gmail.com>.
On Nov 10, 2009, at 2:23 AM, Rex Wang wrote:
> Hi dear all,
> The BlueprintMBean design has finished. I'd like to put the api
> codes in sandbox and request review comments, but seems I can not
> create a folder for myself in the sandbox? How to get that?
Hmm. Don't know what might be wrong, offhand... What is the error you
are getting?
--kevan
Re: Mbeans for Blueprint
Posted by Rex Wang <rw...@gmail.com>.
Hi dear all,
The BlueprintMBean design has finished. I'd like to put the api codes in
sandbox and request review comments, but seems I can not create a folder for
myself in the sandbox? How to get that?
Thanks in advance!
-Rex
2009/10/31 Rex Wang <rw...@gmail.com>
>
>
> 2009/10/30 Guillaume Nodet <gn...@gmail.com>
>
>> I would think each blueprint bundle managed by this extender would be
>>
>> an entry in the tabular data and contain several informations,
>> including the state and last event(s), so that the error would be
>> available (or maybe it should be available directly).
>>
>> Agree. Then the implement of such mbean have to be a BlueprintListener so
> that it can receive the last event of each blueprint bundle?
>
> -Rex
>
>>
>> On Fri, Oct 30, 2009 at 10:41, Rick McGuire <ri...@gmail.com> wrote:
>> > 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
>> >> <ma...@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
>> >>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
Re: Mbeans for Blueprint
Posted by Rex Wang <rw...@gmail.com>.
2009/10/30 Guillaume Nodet <gn...@gmail.com>
> I would think each blueprint bundle managed by this extender would be
> an entry in the tabular data and contain several informations,
> including the state and last event(s), so that the error would be
> available (or maybe it should be available directly).
>
> Agree. Then the implement of such mbean have to be a BlueprintListener so
that it can receive the last event of each blueprint bundle?
-Rex
>
> On Fri, Oct 30, 2009 at 10:41, Rick McGuire <ri...@gmail.com> wrote:
> > Rex Wang wrote:
> >>
> >>
> >> 2009/10/30 Guillaume Nodet <gnodet@gmail.com <ma...@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
> >> <ma...@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
> >>
> >>
> >
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: Mbeans for Blueprint
Posted by Guillaume Nodet <gn...@gmail.com>.
I would think each blueprint bundle managed by this extender would be
an entry in the tabular data and contain several informations,
including the state and last event(s), so that the error would be
available (or maybe it should be available directly).
On Fri, Oct 30, 2009 at 10:41, Rick McGuire <ri...@gmail.com> wrote:
> Rex Wang wrote:
>>
>>
>> 2009/10/30 Guillaume Nodet <gnodet@gmail.com <ma...@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
>> <ma...@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
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Mbeans for Blueprint
Posted by Rick McGuire <ri...@gmail.com>.
Rex Wang wrote:
>
>
> 2009/10/30 Guillaume Nodet <gnodet@gmail.com <ma...@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
> <ma...@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
>
>
Re: Mbeans for Blueprint
Posted by Rex Wang <rw...@gmail.com>.
2009/10/30 Guillaume Nodet <gn...@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.
-Rex
> On Fri, Oct 30, 2009 at 06:54, Rex Wang <rw...@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
>
Re: Mbeans for Blueprint
Posted by Guillaume Nodet <gn...@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.
On Fri, Oct 30, 2009 at 06:54, Rex Wang <rw...@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
Re: Mbeans for Blueprint
Posted by Guillaume Nodet <gn...@gmail.com>.
I think those are two separate concerns. What we were discussion is
to expose one mbean for the blueprint extender that would allow
monitoring the state of the extender and various blueprint bundles.
I think what you are proposing is to allow a user to expose beans over
JMX. I do agree that this is worthwhile, but that's a totally
different discussion imho.
On Fri, Oct 30, 2009 at 15:50, Jarek Gawor <jg...@gmail.com> wrote:
> I agree that we should leverage open mbeans for this as much as we
> can. Also, I was wondering if we should consider creating namespace
> handler that could directly expose individual beans within the
> blueprint container as mbeans. But maybe exposing a bean as a service
> (and therefore as a mbean) is good enough.
>
> Jarek
>
> On Fri, Oct 30, 2009 at 1:54 AM, Rex Wang <rw...@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
Re: Mbeans for Blueprint
Posted by Jarek Gawor <jg...@gmail.com>.
I agree that we should leverage open mbeans for this as much as we
can. Also, I was wondering if we should consider creating namespace
handler that could directly expose individual beans within the
blueprint container as mbeans. But maybe exposing a bean as a service
(and therefore as a mbean) is good enough.
Jarek
On Fri, Oct 30, 2009 at 1:54 AM, Rex Wang <rw...@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
>
Re: Mbeans for Blueprint
Posted by Forrest Xia <fo...@gmail.com>.
On Fri, Oct 30, 2009 at 1:54 PM, Rex Wang <rw...@gmail.com> wrote:
> ...
> 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.
In the spec, there is a requirement like this:
"The solution SHOULD define a JMX integration of critical compendium
services such as the configuration administration, logging, event
administration and preferences services. "
So seems currently there are deviations from this requirement.
Forrest