[jboss-jira] [JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22

[Patson Luk (JIRA)]

    [ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481434#comment-13481434 ] 

Patson Luk commented on JASSIST-270:
------------------------------------

Many thanks for quick reply and suggestion!

I have tried your fix and it works on:
Tomcat 9 / JDK 8
Tomcat 9 / JDK 9
Wildfly 11 / JDK 8

But it does not work on
Wildfly 11 / JDK 9

The problem (which i mostly think is on Wildfly side) is that the Context Class Loader for wildfly - jboss module classloader(Module "org.jboss.as.standalone:main"), cannot load classes provided via Boot-Class-Path entry in MANIFEST.MF which is made available to bootstrap classloader. 

Therefore my workaround is to use the "LoaderClassPath(ClassLoader.getSystemClassLoader())", which in wildfly is the "jdk.internal.loader.ClassLoaders$AppClassLoader" that can actually load bootstrap classes.

I probably need to look deeper into the jdk 9 module/class loading changes to find the right fix. 

As for javassist side, i'm wondering what exactly should `appendSystemPath` do. Should classes available to bootstrap classloader be considered as a part of the "System path"? If so, some context class loader in jdk 9 (like the jboss/wildfly one) might not have access to bootstrap classes.



> Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
> --------------------------------------------------------------------------------------
>
>                 Key: JASSIST-270
>                 URL: https://issues.jboss.org/browse/JASSIST-270
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.22.0-GA
>         Environment: oracle JDK 1.8.0_40
> jboss 7, wildfly 8, wildfly 9, wildfly 10
>            Reporter: Patson Luk
>            Assignee: Shigeru Chiba
>
> 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/778c463e5aa1795591e56916c6c1c3205317fc3e#diff-bfaa8fd6d3084d2b4a978ea2254ccb1cR243] 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 
> {code:java}
>       if (ClassLoader.getSystemClassLoader() != null) {
>                 classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
>             } else {
>                 classPool.appendClassPath(new ClassClassPath(Object.class));
>             }
> {code}
> 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...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent
> 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)