JMXTransAgent with a jboss/wildfly and JDK 1.9 (-Xbootclasspath gone)?

[fwelland]

So JMXTransAgent is working quite well for my usages. As we are pushing into moving to JDK 1.9; I've tripped upon JDK 1.9's removal of Xbootclasspath in favor of 'patch-module' or something like that.

In the JDK 1.8 era, I've been using some additional JDK_OPTS like so:

export JAVA_OPTS="-Xbootclasspath:/opt/jboss-eap-7.1.0/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.7.Final-redhat-1.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djmxtrans.agent.premain.waitForCustomMBeanServer=true -javaagent:/opt/jmxtrans-agent-1.2.8-SNAPSHOT.jar=/opt/jmxtrans-agent.xml"

So this doesn't work in JDK 1.9. Is there any simple tweak for this? -Xbootclasspath/a , which still seems supported in JDK 1.9, gets same result as if no boot classpath was used (in JDK 1.8, or JDK 1.9) : LogManager not installed.

[alvarolop]

Hello @fwelland, did you have any progress with your issue? I am migrating from JDK 1.8 to JDK 11 and I am facing the same issue. If someone could help, I can provide some logs, etc.

[fwelland]

No.
I kinda think (but not 100% sure), JMXAgent used in this fashion, just something that does not work in JDKs > 8.

[alvarolop]

And how did you workaround this issue? using plain jmxtrans? or not upgrading to JDK > 1.8?

[fwelland]

We didn't, yet.

Some of the last work that was using JMX transagent in this fashion, it being migrated to JDK 11 right about now; those engineers haven't really tackled the issue yet.

Separately, I've worked on several wildfly message based processors: Wildfly 20+ and JDK 11 or JDK 17. Since they were greenfield and I knew about the JMXtransagent problem, I didn't even consider it as a option. Rather we built a simple timer based bean. With each fire, it just 'throbs' out a few app oriented processing stats and JVM stats that are important to us to logs and ultimately to a log aggregator, in this case Splunk.

[alvarolop]

Ok, it seems that we will have to look for other alternatives, too. Thank you very much!