JDK-6510634 : Inconsistent behavior of isInstanceOf(name,"javax.management.NotificationEmitter") for StandardMBean
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2007-01-08
  • Updated: 2010-07-29
  • Resolved: 2008-06-18
Related Reports
Duplicate :  
JDK-6624232 - Add GetResource interface to control MBeanServer.getClassLoaderFor and .isInstanceOf
Description
If an MBean that implements NotificationEmitter is wrapped in StandardMBean, then
  MBeanServer.isInstanceOf(name,"javax.management.NotificationEmitter") yields true,
but 
  MBeanServer.addNotificationListener(name,...) fails with the following exception

MBean <name> does not implement javax.management.NotificationEmitter
javax.management.RuntimeOperationsException: MBean <name> does not implement javax.management.NotificationEmitter
Comments
EVALUATION The current plan is: * define a new interface DynamicWrapperMBean that allows you to define what object and ClassLoader are used in isInstanceOf; * make StandardMBean implement that interface; * provide a StandardMBean option that causes the new methods to report on the contained resource rather than the StandardMBean instance itself (this cannot be the default behaviour because it might break existing code); * recommend that new code set this option on all StandardMBean instances. I am therefore closing this CR as a duplicate of the one that introduces DynamicWrapperMBean.
18-06-2008
EVALUATION The root cause is that the class name returned by StandardMBean.getMBeanInfo().getClassName() is the name of the contained resource, rather than "javax.management.StandardMBean". Therefore the current behaviour is correct according to the specification of MBeanServer.isInstanceOf. We fall into the case covered by this paragraph: "Otherwise, if L successfully loads both N and className, and the second class is assignable from the first, the result is true." Changing the behaviour of StandardMBean so the getClassName() is different would be likely to break existing code. But perhaps we could change the result of isInstanceOf in this case without breakage. It's hard to see exactly how this might be specified, though. Perhaps a special case for StandardMBean? My inclination is to close this as Will Not Fix, but I'm hesitating, because it is a fairly nasty gotcha.
10-01-2007
WORK AROUND When <impl> is a NotificationEmitter, use StandardEmitterMBean instead
08-01-2007
EVALUATION This should remain a very rare corner case: there's no reason to wrap a NotificationEmitter in a StandardMBean, you should use StandardEmitterMBean instead.
08-01-2007