You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Alasdair Nottingham <no...@apache.org> on 2011/06/27 21:07:38 UTC
JMX whiteboard project
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
think it would make more sense for a service filter like this:
(|(objectClass=javax.management.MBeanRegistration)(jmx.objectname=))
what do people think?
Alasdair
--
Alasdair Nottingham
not@apache.org
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
On 30 June 2011 07:38, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am Montag, den 27.06.2011, 20:45 +0100 schrieb Alasdair Nottingham:
> > On 27 June 2011 20:19, Felix Meschberger <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Montag, den 27.06.2011, 20:45 +0100 schrieb Alasdair Nottingham:
> On 27 June 2011 20:19, Felix Meschberger <fm...@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).
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
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Alasdair,
Am Donnerstag, den 07.07.2011, 22:21 +0100 schrieb Alasdair Nottingham:
> Hi,
>
> In case you missed it I have committed and resolved 700, 701, 702.
Yes, I saw it. Thanks a lot.
Regards
Felix
>
> On 6 July 2011 06:57, Felix Meschberger <fm...@adobe.com> wrote:
>
> > Hi
> >
> > Thanks for applying the 700 and 701 patches.
> >
> > I have created and attached a new patch for 702 which should be
> > applicable to a Rev. 1143254 checkout.
> >
> > Regards
> > Felix
> >
> > Am Dienstag, den 05.07.2011, 15:09 +0100 schrieb Alasdair Nottingham:
> > > Hi,
> > >
> > > I've applied 700 and 701. The patch for 702 doesn't work for me though. I
> > > think that is because it is a patch on 700, not 701.
> > >
> > > Alasdair
> > >
> > > On 5 July 2011 13:44, Felix Meschberger <fm...@adobe.com> wrote:
> > >
> > > > Hi
> > > >
> > > > I have created ARIES-701 [1] and ARIES-702 [2] showing where this all
> > > > might lead to..
> > > >
> > > > Regards
> > > > Felix
> > > >
> > > > [1] https://issues.apache.org/jira/browse/ARIES-701
> > > > [2] https://issues.apache.org/jira/browse/ARIES-702
> > > >
> > > > 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.
> > > > >
> > > > > Thanks
> > > > > Alasdair
> > > > >
> > > > > On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
In case you missed it I have committed and resolved 700, 701, 702.
On 6 July 2011 06:57, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> Thanks for applying the 700 and 701 patches.
>
> I have created and attached a new patch for 702 which should be
> applicable to a Rev. 1143254 checkout.
>
> Regards
> Felix
>
> Am Dienstag, den 05.07.2011, 15:09 +0100 schrieb Alasdair Nottingham:
> > Hi,
> >
> > I've applied 700 and 701. The patch for 702 doesn't work for me though. I
> > think that is because it is a patch on 700, not 701.
> >
> > Alasdair
> >
> > On 5 July 2011 13:44, Felix Meschberger <fm...@adobe.com> wrote:
> >
> > > Hi
> > >
> > > I have created ARIES-701 [1] and ARIES-702 [2] showing where this all
> > > might lead to..
> > >
> > > Regards
> > > Felix
> > >
> > > [1] https://issues.apache.org/jira/browse/ARIES-701
> > > [2] https://issues.apache.org/jira/browse/ARIES-702
> > >
> > > 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.
> > > >
> > > > Thanks
> > > > Alasdair
> > > >
> > > > On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Thanks for applying the 700 and 701 patches.
I have created and attached a new patch for 702 which should be
applicable to a Rev. 1143254 checkout.
Regards
Felix
Am Dienstag, den 05.07.2011, 15:09 +0100 schrieb Alasdair Nottingham:
> Hi,
>
> I've applied 700 and 701. The patch for 702 doesn't work for me though. I
> think that is because it is a patch on 700, not 701.
>
> Alasdair
>
> On 5 July 2011 13:44, Felix Meschberger <fm...@adobe.com> wrote:
>
> > Hi
> >
> > I have created ARIES-701 [1] and ARIES-702 [2] showing where this all
> > might lead to..
> >
> > Regards
> > Felix
> >
> > [1] https://issues.apache.org/jira/browse/ARIES-701
> > [2] https://issues.apache.org/jira/browse/ARIES-702
> >
> > 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.
> > >
> > > Thanks
> > > Alasdair
> > >
> > > On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
I've applied 700 and 701. The patch for 702 doesn't work for me though. I
think that is because it is a patch on 700, not 701.
Alasdair
On 5 July 2011 13:44, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> I have created ARIES-701 [1] and ARIES-702 [2] showing where this all
> might lead to..
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/ARIES-701
> [2] https://issues.apache.org/jira/browse/ARIES-702
>
> 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.
> >
> > Thanks
> > Alasdair
> >
> > On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
I have created ARIES-701 [1] and ARIES-702 [2] showing where this all
might lead to..
Regards
Felix
[1] https://issues.apache.org/jira/browse/ARIES-701
[2] https://issues.apache.org/jira/browse/ARIES-702
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.
>
> Thanks
> Alasdair
>
> On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
On 8 July 2011 14:34, Felix Meschberger <fm...@adobe.com> wrote:
> Hi,
>
> Am Freitag, den 08.07.2011, 09:50 +0100 schrieb Alasdair Nottingham:
> > On 8 July 2011 08:24, Felix Meschberger <fm...@adobe.com> wrote:
> >
> > > Hi Alasdair,
> > >
> > > Am Donnerstag, den 07.07.2011, 22:25 +0100 schrieb Alasdair Nottingham:
> > > > On 5 July 2011 13:15, Felix Meschberger <fm...@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?
> > >
> > > Good point. How about combining these approaches ?
> > >
> > > * inspect objectClass property and if there is an *MBean in
> > > there use it
> > > * otherwise revert to reflection
> > >
> > >
> > That would work. We could also do reflection first, but validate it
> against
> > objectClass although that might be less efficient.
>
> We don't have to validate since the service object must implement the
> interfaces listed in the object class property - this is verified by the
> framework.
>
>
That wasn't what I was saying. A service can implement interfaces not
referenced by objectClass. So
I'm saying that where you find multiple interfaces that end MBean are
implemented we would decide
which one to use based on the objectClass attribute. So if you implement two
interfaces ending MBean
we would use the one the MBean was published under.
> >
> >
> > > On the other hand, if neither PoolingMean nor LifecycleMBean extend the
> > > DynamicMBean interface it looks kind of weird anyway .. To my knowledge
> > > JMX only supports a single *MBean interface and does not combine,
> > > right ?
> > >
> >
> > I agree it does look weird, however we are already moving away from the
> > "normal" StandardMBean conventions here. We don't require the impl and
> MBean
> > interface to be in the same package. Also while a StandardMBean pattern
> > doesn't support this I'm not so sure about DynamicMBeans. I agree this is
> a
> > corner case, but I still think it might be worth doing.
>
> ok
>
> Regards
> Felix
>
> >
> >
> > >
> > > Regards
> > > Felix
> > >
> > > >
> > > > Alasdair
> > > >
> > > >
> > > > > Regards
> > > > > Felix
> > > >
> > > >
> > > > > >
> > > > > > Thanks
> > > > > > Alasdair
> > > > > >
> > > > > > On 5 July 2011 08:03, Felix Meschberger <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Freitag, den 08.07.2011, 09:50 +0100 schrieb Alasdair Nottingham:
> On 8 July 2011 08:24, Felix Meschberger <fm...@adobe.com> wrote:
>
> > Hi Alasdair,
> >
> > Am Donnerstag, den 07.07.2011, 22:25 +0100 schrieb Alasdair Nottingham:
> > > On 5 July 2011 13:15, Felix Meschberger <fm...@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?
> >
> > Good point. How about combining these approaches ?
> >
> > * inspect objectClass property and if there is an *MBean in
> > there use it
> > * otherwise revert to reflection
> >
> >
> That would work. We could also do reflection first, but validate it against
> objectClass although that might be less efficient.
We don't have to validate since the service object must implement the
interfaces listed in the object class property - this is verified by the
framework.
>
>
> > On the other hand, if neither PoolingMean nor LifecycleMBean extend the
> > DynamicMBean interface it looks kind of weird anyway .. To my knowledge
> > JMX only supports a single *MBean interface and does not combine,
> > right ?
> >
>
> I agree it does look weird, however we are already moving away from the
> "normal" StandardMBean conventions here. We don't require the impl and MBean
> interface to be in the same package. Also while a StandardMBean pattern
> doesn't support this I'm not so sure about DynamicMBeans. I agree this is a
> corner case, but I still think it might be worth doing.
ok
Regards
Felix
>
>
> >
> > Regards
> > Felix
> >
> > >
> > > Alasdair
> > >
> > >
> > > > Regards
> > > > Felix
> > >
> > >
> > > > >
> > > > > Thanks
> > > > > Alasdair
> > > > >
> > > > > On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
On 8 July 2011 08:24, Felix Meschberger <fm...@adobe.com> wrote:
> Hi Alasdair,
>
> Am Donnerstag, den 07.07.2011, 22:25 +0100 schrieb Alasdair Nottingham:
> > On 5 July 2011 13:15, Felix Meschberger <fm...@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?
>
> Good point. How about combining these approaches ?
>
> * inspect objectClass property and if there is an *MBean in
> there use it
> * otherwise revert to reflection
>
>
That would work. We could also do reflection first, but validate it against
objectClass although that might be less efficient.
> On the other hand, if neither PoolingMean nor LifecycleMBean extend the
> DynamicMBean interface it looks kind of weird anyway .. To my knowledge
> JMX only supports a single *MBean interface and does not combine,
> right ?
>
I agree it does look weird, however we are already moving away from the
"normal" StandardMBean conventions here. We don't require the impl and MBean
interface to be in the same package. Also while a StandardMBean pattern
doesn't support this I'm not so sure about DynamicMBeans. I agree this is a
corner case, but I still think it might be worth doing.
>
> Regards
> Felix
>
> >
> > Alasdair
> >
> >
> > > Regards
> > > Felix
> >
> >
> > > >
> > > > Thanks
> > > > Alasdair
> > > >
> > > > On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Alasdair,
Am Donnerstag, den 07.07.2011, 22:25 +0100 schrieb Alasdair Nottingham:
> On 5 July 2011 13:15, Felix Meschberger <fm...@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?
Good point. How about combining these approaches ?
* inspect objectClass property and if there is an *MBean in
there use it
* otherwise revert to reflection
On the other hand, if neither PoolingMean nor LifecycleMBean extend the
DynamicMBean interface it looks kind of weird anyway .. To my knowledge
JMX only supports a single *MBean interface and does not combine,
right ?
Regards
Felix
>
> Alasdair
>
>
> > Regards
> > Felix
>
>
> > >
> > > Thanks
> > > Alasdair
> > >
> > > On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
On 5 July 2011 13:15, Felix Meschberger <fm...@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 <fm...@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 <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
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 ;-)
Regards
Felix
>
> Thanks
> Alasdair
>
> On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
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.
Thanks
Alasdair
On 5 July 2011 08:03, Felix Meschberger <fm...@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 <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
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 <fm...@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
> > >
> >
> >
> >
>
>
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am Dienstag, den 28.06.2011, 12:20 +0200 schrieb Jacek Laskowski:
> On Mon, Jun 27, 2011 at 9:45 PM, Alasdair Nottingham <no...@apache.org> wrote:
>
> > Overall based on this I think a more correct filter would be this:
> >
> > (&(objectClass=*MBean)(|(objectClass=javax.management.MBeanRegistration)(jmx.objectname=)))
>
> I'm still learning and may be totally wrong, so am asking for excuse
> in advance. I'd bet the book "OSGi in Action" and the spec itself (see
> 3.2.7 Filter Syntax) say that to check for existence of an attribute
> you should use present ::= attr ’=*’. Is that what the last filter is
> supposed to achieve?
Yes, I think so.
Regards
Felix
>
> Jacek
>
Re: JMX whiteboard project
Posted by Jacek Laskowski <ja...@japila.pl>.
On Tue, Jun 28, 2011 at 8:37 PM, Alasdair Nottingham <no...@apache.org> wrote:
> I've no idea what OSGi in Action says.
Although it follows the spec in this matter (as does the entire
content) and doesn't add up to the discussion much, but for the sake
of completeness, I can help with it as I'm reading it now and am its
fan from the very first page.
On page 129 there's a greyed box "A quick guide to using LDAP queries"
with the following:
"Determine if an attribute exists:
(name=*)"
That's when I learnt it should've contained the asterisk, else it's
incomplete and should be reported as such by the query parser, I
believe.
Jacek
--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
On 28 June 2011 11:20, Jacek Laskowski <ja...@japila.pl> wrote:
> On Mon, Jun 27, 2011 at 9:45 PM, Alasdair Nottingham <no...@apache.org>
> wrote:
>
> > Overall based on this I think a more correct filter would be this:
> >
> >
> (&(objectClass=*MBean)(|(objectClass=javax.management.MBeanRegistration)(jmx.objectname=)))
>
> I'm still learning and may be totally wrong, so am asking for excuse
> in advance. I'd bet the book "OSGi in Action" and the spec itself (see
> 3.2.7 Filter Syntax) say that to check for existence of an attribute
> you should use present ::= attr ’=*’. Is that what the last filter is
> supposed to achieve?
>
The spec does indeed say that the query should be:
(&(objectClass=*MBean)(|(objectClass=javax.management.MBeanRegistration)(jmx.objectname=*)))
I'm also sure I've seen my previous example working. It is something I want
to check into because I'm pretty sure the remote services assumes attr = can
be used. I've no idea what OSGi in Action says.
Alasdair
>
> Jacek
>
> --
> Jacek Laskowski
> Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
> Warszawa JUG conference = Confitura (formerly Javarsovia) ::
> http://confitura.pl
>
--
Alasdair Nottingham
not@apache.org
Re: JMX whiteboard project
Posted by Jacek Laskowski <ja...@japila.pl>.
On Mon, Jun 27, 2011 at 9:45 PM, Alasdair Nottingham <no...@apache.org> wrote:
> Overall based on this I think a more correct filter would be this:
>
> (&(objectClass=*MBean)(|(objectClass=javax.management.MBeanRegistration)(jmx.objectname=)))
I'm still learning and may be totally wrong, so am asking for excuse
in advance. I'd bet the book "OSGi in Action" and the spec itself (see
3.2.7 Filter Syntax) say that to check for existence of an attribute
you should use present ::= attr ’=*’. Is that what the last filter is
supposed to achieve?
Jacek
--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
Re: JMX whiteboard project
Posted by Alasdair Nottingham <no...@apache.org>.
On 27 June 2011 20:19, Felix Meschberger <fm...@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
Re: JMX whiteboard project
Posted by Felix Meschberger <fm...@gmail.com>.
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:
- 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
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.
All in all, I think the original filter sounds more correct.
Regards
Felix
> Alasdair
>