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, 07 Jul 2011 21:25:31 GMT
On 5 July 2011 13:15, Felix Meschberger <fmeschbe@adobe.com> wrote:

> Hi,
>
> Am Dienstag, den 05.07.2011, 12:50 +0100 schrieb Alasdair Nottingham:
> > Hi,
> >
> > This is amazing timing. I've hit exactly this problem while writing the
> code
> > for ARIES-686.
>
> ;-)
>
> >
> > I agree with your proposal, although when you describe 2 when you say
> you'll
> > look to see if the MBean implements a *MBean interface do you mean you
> will
> > use reflection, or look at the interfaces published into the service
> > registry? I think I'd like it to be the latter.
>
> If I drop the "(objectClass=*MBean)" term from the filter, I don't care
> for what is actually registered and the only means remaining is the
> jmx.objectname service property.
>
> Thus I use reflection.
>
> In any case, it seems to be essential to not require the *MBean
> interface to be exported by the MBean bundles (and consequently not to
> import them in the Whiteboard support bundle.
>
> But I could live well with using "(objectClass=*MBean)" (instead of
> (jmx.objectname=*)) as the filter and inspect the objectClass for the
> MBean interface. This would be closer to my original code ;-)
>
>
I'm wondering if we should look at the objectClass parameter in combination.
I might be worrying about a weird edge case, but I could see this happening.
Imagine the following object:

class MyManageableObject implements PoolingMBean, LifecycleMBean
{
}

this, I think, is not normal for StandardMBeans, but with the current 702
fix MyManageableObject could be registered using PoolingMBean, and we
publish using LifecycleMBean. I'm just mainly thinking about using
objectClass to aid disambiguation. What do you think?

Alasdair


> Regards
> Felix


> >
> > Thanks
> > Alasdair
> >
> > On 5 July 2011 08:03, Felix Meschberger <fmeschbe@adobe.com> wrote:
> >
> > > Hi,
> > >
> > > I think I missed a problematic point: Standard MBeans registered with
> > > the <classname>MBean pattern require that the implementation and the
> > > MBean interface reside in the same package. Not very practical for OSGi
> > > where the MBean interface of course must be exposed.
> > >
> > > So, I think we should probably drop the requirement for the MBean to
> > > exposed with an interface matching "*MBean".
> > >
> > > I still don't like to require the MBeanRegistration interface to be
> used
> > > in the registration. It is kind of like a helper interface not
> > > identifying the primary purpose of the MBean.
> > >
> > > How about changing the filter to just be (jmx.objectname=*). If the
> > > actual property is an empty string (or is not a single-value String),
> > > the object is expected to implement the MBeanRegistration interface. If
> > > not, an ERROR level message is logged and the service ignored.
> > >
> > > Now for the actual service object being registered:
> > > 1 if the service implements the DynamicMBean interface, use it
> > >   right away as the object to register
> > > 2 otherwise see whether the object implements an interface whose
> > >   name matches the <simple-class-name>MBean pattern. If so, wrap
> > >   the object with a StandardMBean class using the interface as
> > >   the MBean interface (and log this at INFO level)
> > > 3 otherwise log an ERROR level message and ignore the service
> > >
> > > Note that using the simple-class-name in the second step is a deviation
> > > from the JMX Spec which requires the MBean interface to reside in the
> > > same package as the MBean object.
> > >
> > > To make this work, the mbeanTracker ServiceTracker must be modified to
> > > actually track all services (this is a generic bug to be fixed,
> > > ARIES-700).
> > >
> > > Regards
> > > Felix
> > >
> > > 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.
> > > >
> > > > 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