aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Re: Mbeans for Blueprint
Date Thu, 19 Nov 2009 07:13:04 GMT
Thanks for comments! My reply is as follows :-)

2009/11/19 Alasdair Nottingham <>

> Hi,
> I haven't had a chance to look at the code, but based on the email
> archive I agree with using the openmbean open type capabilities.
> I know this is different from the approach you are taking, but I would
> have a single MBean for each BlueprintContainer service instance. This
> MBean should allow the metadata to be queried. This way we can update
> the the JMXAgent being created under ARIES-29 to register the MBeans
> when a BlueprintContainer is registered.
The reason why we adopt this approach is because of the intent to keep
consistent with the current design of RFC-139. I hope our MBean implement
can be easily integrated and keep the process and behavior the same with
other MBeans in the JMX agent, so the code style and interface definition is
fairly similar with the api definition in that spec.

> There is a discussion on geronimo mailing list about tracking the
> events. I am not sure why you need to do this, and I'm not sure why an
> EventAdmin MBean would be needed for this. If you register a
> BlueprintListener the blueprint container is required to replay the
> last event for each bundle. This would only get the last event, but if
> that is a failed event then that is useful for debug.
Sorry for the misunderstanding, when I first started working on those, I was
thinking to leverage some sorts of  "EventAdmin MBean" to track blueprint
events without relying on the blueprint APIs(i.e. BlueprintListener). As it
evolved, that dropped out. Since such MBean is to track blueprint
containers, it is reasonable to import blueprint packages. Hence we also
design a state mbean, which eventualy using a Blueprint Listener when
implement it, to track the blueprint events, which represents the state of
blueprint bundle. The ability to get the information of failed deployed
blueprint bundles and their diagnosis messages is a key point for
bluepirnt's remote management.

> I assume geronimo will be using the blueprint implementation in aries,
> perhaps we can look at providing some form of API for an MBean to use
> to get more useful debug information.
Thanks, glad to see that :-)


> Alasdair
> 2009/11/18 Rex Wang <>:
> > Hi, Dear Aries Devs,
> > I am Rex from Geronimo Community. Currently, we are working on defining a
> > couple of MBeans to track Blueprint bundles. You know, in RFC-139 there
> is
> > no such contents designed for that, but blueprint is a really important
> > component in osgi framework, and we need leverage such MBeans for remote
> > management in future geronimo. We also did a quick look on karaf and
> spring
> > dm, but not find them using mbeans to manage the state of blueprint. So I
> > hope the works we are doing are helpful as a complement of RFC-139.
> > Jarek and Guillaume remind me Aries project is a more appropriate place
> to
> > host such MBeans, so I would like to raise such discussion here and
> > contribute our jobs to Aries if it is welcome :-)
> > I put our jobs to my sandbox in Geronimo svn temporarily:
> >
> > That is the current definition of the blueprint MBeans, and we try keep
> the
> > code style consistent with other services in RFC-139. There are also some
> > initial discussions in geronimo, so if you are interesting on the topics,
> > please search the archive of geronimo mailing list. We have started the
> > implement work, but I think before we go farther on the road, the
> comments
> > from your guys is really important to us. Thanks in advance.
> >
> > Best regards!
> > -Rex
> >
> --
> Alasdair Nottingham

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message