]
Shigeru Chiba edited comment on JASSIST-270 at 10/24/17 2:31 PM:
-----------------------------------------------------------------
Thank you for drilling down the problem!
This is a sort of bug caused by the last-minutes hassle due to jigsaw.
It seems that the basic behavior of class loading is not compatible between Java 9 and
earlier ones.
My suggestion to fix this bug is:
{code:java}
if (javassist.bytecode.ClassFile.MAJOR_VERSION < javassist.bytecode.ClassFile.JAVA_9)
{
return appendClassPath(new ClassClassPath());
}
else {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return appendClassPath(new LoaderClassPath(cl, true));
}
{code}
Does this work with Java 8 and wildfly?
was (Author: chiba):
Thank you for drilling down the problem!
This is a sort of bug caused by the last-minutes hassle due to jigsaw.
It seems that the basic behavior of class loading is not compatible between Java 9 and
earlier ones.
My suggestion to fix this bug is:
{{
if (javassist.bytecode.ClassFile.MAJOR_VERSION < javassist.bytecode.ClassFile.JAVA_9)
{
return appendClassPath(new ClassClassPath());
}
else {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return appendClassPath(new LoaderClassPath(cl, true));
}
}}
Does this work with Java 8 and wildfly?
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/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
{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!