]
Kabir Khan commented on WFLY-3661:
----------------------------------
I'm travelling with intermittent WiFi access, so I only really read the introduction.
So apologies if I am about to miss something. Basically the PluggableMBeanServer has a set
of delegates. One of these is the real underlying MBeanServer, the others are various
read-only facades for things like the jmx representation of our management APIs, JSR77
etc. None of these facades allow registering anything.
So, I think it would be safe in this case to do something like
{code}
@Override
public ObjectInstance registerMBean(Object object, ObjectName name) throws
InstanceAlreadyExistsException,
MBeanRegistrationException, NotCompliantMBeanException {
--SNIP--
//Your explanation here :-)
delegate = name == null ? rootMBeanServer : findDelegateForNewObject(name);
--SNIP--
}
{code}
PluggableMBeanServerImpl.findDelegateForNewObject() rejects null
ObjectName arg
-------------------------------------------------------------------------------
Key: WFLY-3661
URL:
https://issues.jboss.org/browse/WFLY-3661
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JMX
Affects Versions: 8.0.0.Final
Reporter: Jess Holle
Assignee: Kabir Khan
According to the Javadoc on MBeanRegistration.preRegister(), one may register an MBean
with a null ObjectName and let the MBean's preRegister() method compute the
ObjectName.
Unfortunately, org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegateForNewObject()
violates this contract -- throwing an exception when the incoming ObjectName is null.
This is a clear bug which breaks numerous JMX MBeans I've authored, which compute
their own ObjectNames within preRegister().
Ideally the result of preRegister would be used as an input to
findDelegateForNewObject(), but unfortunately one of the inputs to preRegister() is the
MBeanServer, which is, of course, what findDelegateForNewObject() is looking up. Given
this circularity, it would seem that findDelegateForNewObject() should simply return
rootMBeanServer for null ObjectName inputs. In any case it should not entirely fail to
register such MBeans.
Fortunately, I have a utility wrapper around MBean registration, so I've added the
following hack immediately prior to actually registering the MBean to workaround this
issue:
/* Hack to work around JBoss Wildfly bug
(
https://issues.jboss.org/browse/WFLY-3661).
This isn't really quite correct, of course, since this means preRegister()
will get called twice,
but it appears to be about the best we can do.
*/
if ( objectName == null )
if ( mbean instanceof MBeanRegistration )
if ( "org.jboss.as.jmx.PluggableMBeanServerImpl".equals(
mbeanserver.getClass().getName() ) )
objectName = ((MBeanRegistration)mbean).preRegister( mbeanserver, objectName
);
where mbeanserver is obtained via ManagementFactory.getPlatformMBeanServer().