Using Java 11, we've found that our integration tests using WildFly 18 run
correctly and provide the instrumentation and reports when using the
OpenJDK11-Hotspot VM JDK.
However, if we run the same build with the OpenJDK-11-J9 VM (the eclipse J9
runtime) - this occurs:
INFO: Starting container with: [C:\Development\Java\JDK\bin\java,
-D[Standalone], -Xmx10G,
-Djava.library.path=C:\\Development\\WildFly\\standalone\\lib,
-javaagent:C:\\Development\\portal\\libs\\DB\\target\\jacocoagent-0.8.5.jar=destfile=C:\\Development\\portal\\libs\\DB\\target\\jacoco.exec,
-ea, -Djboss.home.dir=C:\Development\WildFly,
-Dorg.jboss.boot.log.file=C:\Development\WildFly\standalone\log\server.log,
-Dlogging.configuration=file:C:\Development\WildFly\standalone\configuration\logging.properties,
-jar, C:\Development\WildFly\jboss-modules.jar, -mp,
C:\Development\WildFly\modules, org.jboss.as.standalone,
-Djboss.home.dir=C:\Development\WildFly,
-Djboss.server.base.dir=C:\Development\WildFly\standalone,
-Djboss.server.log.dir=C:\Development\WildFly\standalone\log,
-Djboss.server.config.dir=C:\Development\WildFly\standalone\configuration]
Exception in thread "main" java.lang.NoClassDefFoundError: java.lang.$JaCoCo
at org.jboss.logmanager.LogManager.$jacocoInit(LogManager.java)
at org.jboss.logmanager.LogManager.<clinit>(LogManager.java)
at java.base/java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.base/java.lang.Class.newInstance(Class.java:2082)
at
java.logging/java.util.logging.LogManager$1.run(LogManager.java:239)
at
java.logging/java.util.logging.LogManager$1.run(LogManager.java:223)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:678)
at
java.logging/java.util.logging.LogManager.<clinit>(LogManager.java:223)
at org.jboss.modules.Main.main(Main.java:523)
Caused by: java.lang.ClassNotFoundException: java.lang.$JaCoCo from [Module
"org.jboss.logmanager" version 2.1.14.Final from local module loader
@4f93e763 (finder: local module finder @cbe6fdc3 (roots:
C:\Development\WildFly\modules,C:\Development\WildFly\modules\system\layers\base))]
at
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
... 9 more
We had a very similar issue with another instrumentation library on our
production machines (DynaTrace app monitoring) but were able to fix that by
modifying the startup parameters (adding the logging/modules/Xbootclasspath
options you see above).
Have we stumbled into an incompatibility with Jacoco, or just not hit on
the exact configuration syntax? Please advise so I can either give up,
provide more info, or file a bug report.
Regards and thanks for your time,
-a
--
You received this message because you are subscribed to the Google Groups
"JaCoCo and EclEmma Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/7dc56828-288e-4896-ab24-62c20919555f%40googlegroups.com.