aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: JMX whiteboard project
Date Thu, 30 Jun 2011 18:06:46 GMT
On 30 June 2011 07:38, Felix Meschberger <fmeschbe@adobe.com> wrote:

> Hi,
>
> Am Montag, den 27.06.2011, 20:45 +0100 schrieb Alasdair Nottingham:
> > On 27 June 2011 20:19, Felix Meschberger <fmeschbe@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Am Montag, den 27.06.2011, 20:07 +0100 schrieb Alasdair Nottingham:
> > > > Hi,
> > > >
> > > > I've been looking at the way the whiteboard implementation works and
> I
> > > was
> > > > wondering if it would make sense to change the way it detects mbeans.
> > > > Currently it detects them by looking for:
> > > >
> > > > (objectClass=*MBean). The impl then needs to either have a
> jmx.objectname
> > > > property, or it needs to be javax.management.MBeanRegistration
> extension.
> > > I
> > >
> > > My idea for requiring some MBean interface is that it makes
> registration
> > > extremely easy:
> > >
> >
> > I agree with this goal.
> >
> >
> > >
> > > - either it is a DynamicMBean (or some extension thereof) service
> > > - or it is an interface with MBean suffix which as per the spec
> > >   defines the MBean interface for the bean
> > >
> >
> > OK.
> >
> >
> > >
> > > For the registration then only an ObjectName is required which can be
> > > provided as a service registration property or by implementing the
> > > MBeanRegistration interface (which is also similarly used in the spec
> > > IIRC).
> > >
> > >
> > > > think it would make more sense for a service filter like this:
> > > >
> > > > (|(objectClass=javax.management.MBeanRegistration)(jmx.objectname=))
> > > >
> > > > what do people think?
> > >
> > > By going that way, you will solve the second issue with the filter but
> > > you then have an MBean where you have to find out how to be able to
> > > register (or I may be missing something in more recent JMX specs).
> > >
> > > But then, I don't think we should require the MBeanRegistration
> > > interface as a service interface. Sounds kind of incorrect.
> > >
> >
> > I think if it needs to be an MBeanRegistration then we should require the
> > object to be advertised as an MBeanRegistration. Not putting
> > MBeanRegistration on a service and then relying on it being one is dodgy
> in
> > OSGi. Sure in most cases it'll work, but if someone decides to use
> service
> > hooks to insert a proxy they will probably get this wrong, also you can't
> > make use of the service registry to get the class space consistency.
>
> Sure, if we would rely on this, it would be kind of dodgy. But we don't.
> What the whiteboard support does is check for the jmx.objectname system
> property and a second level whether the interface is implemented.
> Finally, if the service neither has a jmx.objectname property nor is
> implementing a shared MBeanRegistration interface [class], it is simply
> ignored - same as if it would not match your filter - with the
> difference being that the service is not required to be registered with
> the interface (which I really think would be wrong).
>
> I rather see it along the lines of the MetaTypeService which can extract
> information from a ManagedService[Factory] provided it also implements
> another interface (without requiring it to be registered as that
> service).
>

This is really not safe to assume. So many things being based on OSGi could
end up breaking assumptions like this. The service hooks proxying example
would prevent this from working because the MBeanRegistration is not in the
service registry.


>
> Plus we do probably not have a class-space consistency issue in this
> concrete case.
>
> Regards
> Felix
>
> >
> > Overall based on this I think a more correct filter would be this:
> >
> >
> (&(objectClass=*MBean)(|(objectClass=javax.management.MBeanRegistration)(jmx.objectname=)))
> >
> >
> > >
> > > All in all, I think the original filter sounds more correct.
> > >
> > > Regards
> > > Felix
> > >
> > > > Alasdair
> > > >
> > >
> > >
> > >
> >
> >
>
>
>
>


-- 
Alasdair Nottingham
not@apache.org

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