[
https://jira.jboss.org/jira/browse/JBCL-17?page=com.atlassian.jira.plugin...
]
Adrian Brock commented on JBCL-17:
----------------------------------
No, the whole point of using getResource() is to avoid having to invoke loadClass()
on the classloader which will synchronize on the classloader and signal not found by
creating
a ClassNotFoundException.
There's no point doing the getResource() if you always then invoke loadClass()
anyway.
New ClassLoader not finding generated classes in the bootstrap
classloader
--------------------------------------------------------------------------
Key: JBCL-17
URL:
https://jira.jboss.org/jira/browse/JBCL-17
Project: JBoss ClassLoader
Issue Type: Bug
Components: ClassLoader
Affects Versions: JBossCL.2.0.0.Beta12
Reporter: Adrian Brock
Assignee: Adrian Brock
Fix For: JBossCL.2.0.0.Beta13
Attachments: jboss-classloader.jar
An optimisation in the new classloader is causing a backwards compatibility problem.
When we load classes from the parent (bootstrap) classloader,
we first check to see whether we can getResource() on the class file.
This avoids excessive locking when many threads are trying to loadClass() on that
classloader.
However, if the class is a runtime generated class against that classloader
getResource()
will return null, leading to a ClassNotFoundException.
While we've always done this optimization for JBoss ClassLoaders, it looks like we
can't to do
this non-jboss classloaders and maintain backwards compatibility.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira