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 <[email protected]> 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 <[email protected]> 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 [email protected]
