[ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugi... ] Patson Luk updated JASSIST-270: ------------------------------- Description: h3. Description After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code {{CannotCompileException: [source error] no such class: test.TestClass}} h3. Setup # Our agent inject a piece of code with reference to class `test.TestClass` # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR) # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21 h3. Cause With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem The steps are: # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main") # The injected code references class `test.TestClass` # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader. As a workaround, we added {{ if (ClassLoader.getSystemClassLoader() != null) { classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader())); } else { classPool.appendClassPath(new ClassClassPath(Object.class)); } }} on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9. However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out... Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken... Many thanks for your attention! was: h3. Description After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code {{CannotCompileException: [source error] no such class: test.TestClass}} h3. Setup # Our agent inject a piece of code with reference to class `test.TestClass` # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR) # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21 h3. Cause With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem The steps are: # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main") # The injected code references class `test.TestClass` # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader. As a workaround, we added `classPool.appendClassPath(new ClassClassPath(Object.class));` on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem (both jdk 8 and jdk 9) Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken... Many thanks for your attention! -- This message was sent by Atlassian JIRA (v7.5.0#75005)