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.

Reply via email to