aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From adam wojtuniak <adamwojtun...@gmail.com>
Subject Re: [jira] Created: (ARIES-141) Add a factory class to allow the OSGi JMX MBeans to be registered in an external MBean server
Date Thu, 04 Feb 2010 10:03:32 GMT
Hi Alasdair

One solution is to register JMX agent as a service and provide method for
adding and removing external MBeanServer
to the agent servers list. That will solve problem 1. But Iam not sure if
that is good pattern in OSGI since we are using
whiteboard pattern for MBean servers.

Regards,
Adam



On Wed, Feb 3, 2010 at 10:00 PM, Alasdair Nottingham <not@apache.org> wrote:

> Hi,
>
> Back when ARIES-29 was originally raised I expressed a concern about
> the aries agent working the way it does. However I always wanted a
> more flexable approach so we can reuse the MBeans with a different
> agent.
>
> Stepping back for a sec here are my requirements:
>
> 1. I have an MBeanServer that is mine, it is not public and I do not
> want to put it in the service registry to be used by others.
> 2. I would like to have two separate OSGi frameworks running at once
> in a JVM, but without needing to install the bundle into each
> framework.
> 3. I want to control whether MBeans are registered for compendium services.
> 4. I have an MBeanServer that federates multiple MBeanServers
> together. I wish to register the MBean with additional properties to
> allow me to select between the multiple Mbeans that will be available.
>
> As far as I can tell none of these is possible. I like Tim's
> suggestion because I can be in total control of how the management
> agent works and implement 1-4, but still reuse the MBean
> implementations in aries. However looking at the code I think there is
> an possible alternative which I thought I would throw out there. If
> the JMXAgent was available in the service registry I should be able to
> do requirements 1, 3 and 4. However since I want to get 2 in as well I
> think we could have a factory to create JMXAgent instances.
>
> What do you think?
> Alasdair
>
> On 3 February 2010 18:43, adam wojtuniak <adamwojtuniak@gmail.com> wrote:
> > Hi Tim
> >
> > Iam against exposing MBeans outside JMX bundle.
> > Lifecycle of all MBeans is managed by JMX bundle using MBeanHandlers and
> I
> > think it should be this way.
> > In your factory you are using framework MBeans but what will happen if
> you
> > want to use
> > compendium MBeans. They all created based on availability of compendium
> > services which is managed
> > inside JMX bundle. In such a case the outside user will have to manage
> those
> > MBeans
> > by himslef. Even he can't be sure if could get MBean from JMX could be
> not
> > available at the time.
> > Currently the best way to register MBeans in an external MBean server is
> to
> > register the server as a
> > service.
> >
> > Regards,
> > Adam Wojtuniak
> >
> > On Wed, Feb 3, 2010 at 4:21 PM, Tim Mitchell (JIRA) <jira@apache.org>
> wrote:
> >
> >> Add a factory class to allow the OSGi JMX MBeans to be registered in an
> >> external MBean server
> >>
> >>
> ---------------------------------------------------------------------------------------------
> >>
> >>                 Key: ARIES-141
> >>                 URL: https://issues.apache.org/jira/browse/ARIES-141
> >>             Project: Aries
> >>          Issue Type: Improvement
> >>          Components: JMX
> >>            Reporter: Tim Mitchell
> >>            Priority: Minor
> >>         Attachments: JMXFactoryPatch.txt
> >>
> >> Currently there is no way of accessing the Apache Aries MBeans in order
> to
> >> register them in an external MBean server. I am proposing a factory
> class
> >> that will be exported from the jmx bundle that will allow users to
> access
> >> the internal MBean.
> >> I have supplied a patch with my suggested class.
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >>
> >>
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>

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