[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Jess Holle (JIRA)
[ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.... ]
Jess Holle updated WFLY-3661:
-----------------------------
Description:
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().
was:
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 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().
> 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().
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Jess Holle (JIRA)
[ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.... ]
Jess Holle updated WFLY-3661:
-----------------------------
Description:
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 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
was:
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.
> 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 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
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Jess Holle (JIRA)
[ https://issues.jboss.org/browse/WFLY-3661?page=com.atlassian.jira.plugin.... ]
Jess Holle updated WFLY-3661:
-----------------------------
Description:
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 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().
was:
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 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
> 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 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().
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-899) spelling mistakes in the management security domain should be logged better
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-899?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-899:
----------------------------------
Issue Type: Feature Request (was: Bug)
> spelling mistakes in the management security domain should be logged better
> ---------------------------------------------------------------------------
>
> Key: WFLY-899
> URL: https://issues.jboss.org/browse/WFLY-899
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security, Server
> Reporter: Tom Fonteyne
> Assignee: Darran Lofthouse
> Priority: Minor
>
> A spelling mistake in the management security domain prevents the server from starting (good) but the message in the log file is only stating:
> [Host Controller] 08:35:37,672 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> There in fact no previous messages
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1862) NPE during FIND_MBRS when using shared transport
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1862?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1862:
------------------------------------
Sorry I didn't catch this earlier - I only saw this when running the WildFly x-site replication tests. I hadn't run these when testing the SNAPSHOT following JGRP-1859.
> NPE during FIND_MBRS when using shared transport
> ------------------------------------------------
>
> Key: JGRP-1862
> URL: https://issues.jboss.org/browse/JGRP-1862
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> The following code within org.jgroups.protocols.TP.sendToSingleMember(...) throws an NPE if the transport is shared:
> {code}
> Responses responses=(Responses)up(new Event(Event.FIND_MBRS, Arrays.asList(dest)));
> try {
> for(PingData data : responses) {
> if(data.getAddress() != null && data.getAddress().equals(dest)) {
> if((physical_dest=data.getPhysicalAddr()) != null) {
> sendUnicast(physical_dest, buf, offset, length);
> return;
> }
> }
> }
> }
> finally {
> responses.done();
> }
> {code}
> This is because up(Event) always returns null when using a shared transport.
> The same issue affects org.jgroups.protocols.TP.fetchPhysicalAddrs(...):
> {code}
> if(!missing.isEmpty()) {
> Responses rsps=(Responses)up(new Event(Event.FIND_MBRS, missing));
> rsps.done();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1862) NPE during FIND_MBRS when using shared transport
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1862?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1862:
------------------------------------
That's still the plan, but I'm still working on it. The usage of FORK is part of a larger effort that will make channels a 1st class resource WildFly 9.
> NPE during FIND_MBRS when using shared transport
> ------------------------------------------------
>
> Key: JGRP-1862
> URL: https://issues.jboss.org/browse/JGRP-1862
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> The following code within org.jgroups.protocols.TP.sendToSingleMember(...) throws an NPE if the transport is shared:
> {code}
> Responses responses=(Responses)up(new Event(Event.FIND_MBRS, Arrays.asList(dest)));
> try {
> for(PingData data : responses) {
> if(data.getAddress() != null && data.getAddress().equals(dest)) {
> if((physical_dest=data.getPhysicalAddr()) != null) {
> sendUnicast(physical_dest, buf, offset, length);
> return;
> }
> }
> }
> }
> finally {
> responses.done();
> }
> {code}
> This is because up(Event) always returns null when using a shared transport.
> The same issue affects org.jgroups.protocols.TP.fetchPhysicalAddrs(...):
> {code}
> if(!missing.isEmpty()) {
> Responses rsps=(Responses)up(new Event(Event.FIND_MBRS, missing));
> rsps.done();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3661) PluggableMBeanServerImpl.findDelegateForNewObject() rejects null ObjectName arg
by Jess Holle (JIRA)
Jess Holle created WFLY-3661:
--------------------------------
Summary: 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.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early
by Andreas Liebscher (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Andreas Liebscher commented on WFLY-3619:
-----------------------------------------
I already increased the log level for analyzing, I found an older log file and attach it...
> XA END / un-enlist for database connection called to early
> ----------------------------------------------------------
>
> Key: WFLY-3619
> URL: https://issues.jboss.org/browse/WFLY-3619
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, JCA, JPA / Hibernate, Transactions
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64-bit
> JDK 1.8.0_05-b13 64-Bit
> MS SQL Server 2012 database
> Latest MS JDBC driver
> XA datasource
> Reporter: Andreas Liebscher
> Assignee: Scott Marlow
> Priority: Blocker
>
> While trying to port an EE application from JBoss5 to WF8 the following problem occurred:
> EJBs (@Required) using JPA to do some data changes.
> Some changes get already written to the database, others reside in the session cache.
> After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion.
> Then more changes are flushed to the database, but I run in a reproduceable database locking problem.
> After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call.
> There should be exactly one xa transaction active processing all data changes.
> But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction.
> After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour:
> - a connection is enlisted and xa start called
> - the same connection is used for several select / insert / update statements
> - after return of the top EJB call on the same connection xa end and connection un-enlist is called
> - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected.
> Shouldn't xa end be called AFTER beforeCompletion / session flush!?!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months