[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Patson Luk (JIRA)
[ 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
{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...
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
{{
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!
> 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...
> 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)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Patson Luk (JIRA)
[ 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!
> 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
> {{
> 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!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Patson Luk (JIRA)
[ 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 `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!
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, instead of calling `appendSystemPath`, i called `classPool.appendClassPath(new ClassClassPath(Object.class));` and it no longer complains about class loading problem
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!
> 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 `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)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Patson Luk (JIRA)
Patson Luk created JASSIST-270:
----------------------------------
Summary: 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, instead of calling `appendSystemPath`, i called `classPool.appendClassPath(new ClassClassPath(Object.class));` and it no longer complains about class loading problem
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)
8 years, 8 months
[JBoss JIRA] (LOGMGR-179) The configuration API should fail if a configuration being removed is attached to another configuration
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-179?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-179:
--------------------------------------
For most cases this can be quite easily achieved. However with POJO's this introduces some possible complexity of having to know if a POJO object is assigned to a formatter, handler, logger, filter or error manager. An mapping from the POJO name to a configuration type/name may be needed to ensure integrity.
> The configuration API should fail if a configuration being removed is attached to another configuration
> -------------------------------------------------------------------------------------------------------
>
> Key: LOGMGR-179
> URL: https://issues.jboss.org/browse/LOGMGR-179
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: James Perkins
> Assignee: James Perkins
>
> The configuration API will allow the removal of a configuration resource even if that resource is attached to a different configuration. For example you can remove a {{FormatterConfiguration}} even if that formatter is attached to a {{HandlerConfiguration}}. This should be validated and fail if prepared or committed via the {{LogContextConfiguration}} API.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months