-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thread.currentThread().getContextClassLoader() changed from 9.0.0.0.pre2 and 9.0.0.0.rc1 #3082
Comments
yes, it was intentionally - as it was a commandline only feature. the same maybe there is a way to tell groovy which classloader to or you need to set the context classloader yourself: java.lang.Thread.currentThread.setContextClassLoader( here I am not sure what all can happen on environments where threads are On Thu, Jun 25, 2015 at 12:59 AM, Rafer Hazen notifications@github.com
|
Ok, thanks. I've verified that I am able to fix my issues by using |
It appears that the value of
Java::JavaLang::Thread.currentThread.getContextClassLoader
has changed between 9.0.0.0.pre2 and 9.0.0.0.rc1:As you can see above, the the result of
getContextClassLoader
on the current thread is now an instance ofJava::SunMisc::Launcher::AppClassLoader
. It appears thatJRuby.runtime.jruby_class_loader
is unchanged and still an instance ofJava::OrgJrubyUtil::JRubyClassLoader
.Generally, the symptom of this is that java code which uses
Thread.currentThread().getContextClassLoader()
does not have access to classes that have been loaded viarequire
in ruby code, whereas in the past (before rc1) it did.In my case, this is causing trouble in groovy (
GroovyClassLoader
in 2.4.0 in particular), which uses this method to acquire a class loader when it attempts to evaluate some groovy code at runtime. Though the groovy jar has been required (and indeed code from it is running), when it attempts to useThread.currentThread().getContextClassLoader()
, it throwsjava.lang.ClassNotFoundException
because it is using theJava::SunMisc::Launcher::AppClassLoader
class loader which doesn't appear to know anything about the classes available due to therequire
ing of jars in jruby.Was the value of
Thread.currentThread.getContextClassLoader
modified intentionally between pre2 and rc1, and if so is there a workaround for code which usesThread.currentThread.getContextClassLoader
?The text was updated successfully, but these errors were encountered: