I have not tried your example, but I have an educated guess for what is going on. We use org.jboss.as.jmx.PluggableMBeanServerBuilder as an implementation for javax.management.MBeanServerBuilder which is what creates the platform mbean server. The resulting org.jboss.as.jmx.PluggableMBeanServerImpl is what allows the JMX subsystem to expose the management api via jmx. This gets set almost immediately in the boot process in the block at https://github.com/jboss-modules/jboss-modules/blob/1. x/src/main/java/org/jboss/modules/Main.java#L520. I would guess that your javaagent ends up calling getPlatformMBeanServer() before JBoss Modules has had a chance to do its stuff, and as the platform mbean server gets set on the first call to it, you end up with the default implementation of it. This will break things for other users wanting to use the pluggable mbean server too :) Some fixes that come to mind: - wait until we've had a chance to initialise before calling getPlatformMBeanServer() from your agent - make sure that the jmx module is on your javaagent's classpath and replicate what JBoss Modules does before calling getPlatformMBeanServer. For the server org.jboss.as.standalone is used as the boot module, this in turn pulls in the org.jboss.as.jmx module, which has the META-INF/services/org.jboss.as.jmx.PluggableMBeanServerBuilder file to load the proper implementation Thanks, Kabir > On 13 Dec 2017, at 22:19, John Mazzitelli <mazz(a)redhat.com&gt; wrote: > > I'm seeing odd behavior with the JMX API implementation in Wildfly 11. > > If you grab this Makefile and two .java files I use for testing you can see it yourself - just put these in a tmp directory somewhere: > > wget https://raw.githubusercontent.com/jmazzitelli/test/master/ javaagent/Makefile > wget https://raw.githubusercontent.com/jmazzitelli/test/master/ javaagent/TestJavaAgent.java > wget https://raw.githubusercontent.com/jmazzitelli/test/master/ javaagent/TestJavaAgentMXBean.java > > Then just run "make download-wildfly unzip-wildfly compile run" (make sure you don't have other WildFly servers running to avoid port conflicts) > > This runs WF 11 with a -javaagent attached. In the server output, you will see this: > > 16:31:05,290 INFO [stdout] (Test Java Agent Thread) ============================================================= > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) ============================================================= > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) isRegistered: > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) true > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) getMBeanInfo: > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) description: The root node of the server-level management model. > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) #attributes: 19 > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) getAttribute: > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) serverState=reload-required > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames: > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) [] > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryMBeans: > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) [] > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames(null, null): > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) FOUND IT: jboss.as: management-root=server > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) ============================================================= > > You will see SOME JMX APIs can see the MBean "jboss.as:management-root= server", > but queryMBeans and queryNames canNOT (note the empty arrays []). > > But notice getMBeanInfo CAN see it - I can even get the serverState attribute value from that (you can see it is in reload-required state - I see the same behavior even if it was in "running" state). > > But again, queryMBeans returns nothing. > > Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API. > > Finally, note that it seems this MBean "jboss.as:management-root=server" is special - because it is specifically broke - if i switch to querying for "jboss.as:subsystem=transactions" it all works fine, even the query APIs: > > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) queryNames: > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) [jboss.as: subsystem=transactions] > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) queryMBeans: > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]] > > This problem was seen by others as well (with the same MBean I'm trying to get) - see: > > https://github.com/prometheus/jmx_exporter/issues/89 > > The person there claims queryNames is broke but queryMBeans is OK - that does not work in my example either. Neither query API works. > > I searched JIRA, found nothing related to this MBean not being queryable. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Now I see I did not look properly at Mazz's example, sorry! > On 14 Dec 2017, at 13:33, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > > The "jboss.as:management-root=server" mbean *is* special. It represents the management resource at address PathAddress.EMPTY_ADDRESS, and hence it has a PathAddress that can't directly translate to an ObjectName. It has no key/value pairs, and those are required in an ObjectName. So "management-root=server" is a special hard coded name. > > It doesn't surprise me that there's something broken in the handling of that corner case. Can you file a WFCORE please? Please include the details of your queryNames/queryMBeans calls. > > Thanks, > Brian > > > On Thu, Dec 14, 2017 at 4:34 AM, Kabir Khan <kkhan(a)redhat.com&gt; wrote: > I have not tried your example, but I have an educated guess for what is going on. > > We use org.jboss.as.jmx.PluggableMBeanServerBuilder as an implementation for javax.management.MBeanServerBuilder which is what creates the platform mbean server. The resulting org.jboss.as.jmx.PluggableMBeanServerImpl is what allows the JMX subsystem to expose the management api via jmx. > > This gets set almost immediately in the boot process in the block at https://github.com/jboss-modules/jboss-modules/blob/1. x/src/main/java/org/jboss/modules/Main.java#L520. > > I would guess that your javaagent ends up calling getPlatformMBeanServer() before JBoss Modules has had a chance to do its stuff, and as the platform mbean server gets set on the first call to it, you end up with the default implementation of it. This will break things for other users wanting to use the pluggable mbean server too :) > > Some fixes that come to mind: > - wait until we've had a chance to initialise before calling getPlatformMBeanServer() from your agent > - make sure that the jmx module is on your javaagent's classpath and replicate what JBoss Modules does before calling getPlatformMBeanServer. For the server org.jboss.as.standalone is used as the boot module, this in turn pulls in the org.jboss.as.jmx module, which has the META-INF/services/org.jboss.as.jmx.PluggableMBeanServerBuilder file to load the proper implementation > > Thanks, > > Kabir > > > > > On 13 Dec 2017, at 22:19, John Mazzitelli <mazz(a)redhat.com&gt; wrote: > > > > I'm seeing odd behavior with the JMX API implementation in Wildfly 11. > > > > If you grab this Makefile and two .java files I use for testing you can see it yourself - just put these in a tmp directory somewhere: > > > > wget https://raw.githubusercontent.com/jmazzitelli/test/master/ javaagent/Makefile > > wget https://raw.githubusercontent.com/jmazzitelli/test/master/ javaagent/TestJavaAgent.java > > wget https://raw.githubusercontent.com/jmazzitelli/test/master/ javaagent/TestJavaAgentMXBean.java > > > > Then just run "make download-wildfly unzip-wildfly compile run" (make sure you don't have other WildFly servers running to avoid port conflicts) > > > > This runs WF 11 with a -javaagent attached. In the server output, you will see this: > > > > 16:31:05,290 INFO [stdout] (Test Java Agent Thread) ============================================================= > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) ============================================================= > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) isRegistered: > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) true > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) getMBeanInfo: > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) description: The root node of the server-level management model. > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) #attributes: 19 > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) getAttribute: > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) serverState=reload-required > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames: > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) [] > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryMBeans: > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) [] > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) queryNames(null, null): > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:management-root=server > > 16:31:05,291 INFO [stdout] (Test Java Agent Thread) ============================================================= > > > > You will see SOME JMX APIs can see the MBean "jboss.as: management-root=server", > > but queryMBeans and queryNames canNOT (note the empty arrays []). > > > > But notice getMBeanInfo CAN see it - I can even get the serverState attribute value from that (you can see it is in reload-required state - I see the same behavior even if it was in "running" state). > > > > But again, queryMBeans returns nothing. > > > > Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API. > > > > Finally, note that it seems this MBean "jboss.as:management-root=server" is special - because it is specifically broke - if i switch to querying for "jboss.as:subsystem=transactions" it all works fine, even the query APIs: > > > > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) queryNames: > > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) [jboss.as: subsystem=transactions] > > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) queryMBeans: > > 17:16:39,541 INFO [stdout] (Test Java Agent Thread) [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]] > > > > This problem was seen by others as well (with the same MBean I'm trying to get) - see: > > > > https://github.com/prometheus/jmx_exporter/issues/89 > > > > The person there claims queryNames is broke but queryMBeans is OK - that does not work in my example either. Neither query API works. > > > > I searched JIRA, found nothing related to this MBean not being queryable. > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev