Skip to content
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

Closed
rafer opened this issue Jun 24, 2015 · 2 comments

Comments

@rafer
Copy link

rafer commented Jun 24, 2015

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:

JRuby 9.0.0.0.pre2
Java::JavaLang::Thread.currentThread.getContextClassLoader => #<Java::OrgJrubyUtil::JRubyClassLoader:0x619a5dff>
JRuby.runtime.jruby_class_loader => #<Java::OrgJrubyUtil::JRubyClassLoader:0x619a5dff>

JRuby 9.0.0.0.rc1
Java::JavaLang::Thread.currentThread.getContextClassLoader => #<Java::SunMisc::Launcher::AppClassLoader:0x87aac27>
JRuby.runtime.jruby_class_loader => #<Java::OrgJrubyUtil::JRubyClassLoader:0xb1a58a3>

As you can see above, the the result of getContextClassLoader on the current thread is now an instance of Java::SunMisc::Launcher::AppClassLoader. It appears that JRuby.runtime.jruby_class_loader is unchanged and still an instance of Java::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 via require 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 use Thread.currentThread().getContextClassLoader(), it throws java.lang.ClassNotFoundException because it is using the Java::SunMisc::Launcher::AppClassLoader class loader which doesn't appear to know anything about the classes available due to the requireing 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 uses Thread.currentThread.getContextClassLoader?

@mkristian
Copy link
Member

yes, it was intentionally - as it was a commandline only feature. the same
code running via a ScriptingContainer or inside a servlet or any embedded
jruby never worked.

maybe there is a way to tell groovy which classloader to
use: JRuby.runtime.jruby_classloader
that would be best option.

or you need to set the context classloader yourself:

java.lang.Thread.currentThread.setContextClassLoader(
JRuby.runtime.jruby_classloader )

here I am not sure what all can happen on environments where threads are
managed.

On Thu, Jun 25, 2015 at 12:59 AM, Rafer Hazen notifications@github.com
wrote:

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:

JRuby 9.0.0.0.pre2
Java::JavaLang::Thread.currentThread.getContextClassLoader => #Java::OrgJrubyUtil::JRubyClassLoader:0x619a5dff
JRuby.runtime.jruby_class_loader => #Java::OrgJrubyUtil::JRubyClassLoader:0x619a5dff

JRuby 9.0.0.0.rc1
Java::JavaLang::Thread.currentThread.getContextClassLoader => #Java::SunMisc::Launcher::AppClassLoader:0x87aac27
JRuby.runtime.jruby_class_loader => #Java::OrgJrubyUtil::JRubyClassLoader:0xb1a58a3

As you can see above, the the result of getContextClassLoader on the
current thread is now an instance of
Java::SunMisc::Launcher::AppClassLoader. It appears that
JRuby.runtime.jruby_class_loader is unchanged and still an instance of
Java::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 via require 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 use
Thread.currentThread().getContextClassLoader(), it throws
java.lang.ClassNotFoundException because it is using the
Java::SunMisc::Launcher::AppClassLoader class loader which doesn't appear
to know anything about the classes available due to the requireing 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 uses Thread.currentThread.getContextClassLoader?


Reply to this email directly or view it on GitHub
#3082.

@rafer
Copy link
Author

rafer commented Jun 30, 2015

Ok, thanks. I've verified that I am able to fix my issues by using Thread.currentThread.setContextClassLoader() as you have suggested. I think that groovy's use of getContextClassLoader may be the true bug. It seems like they should perhaps use this.class.getClassLoader in it's place. Thanks for your help.

@rafer rafer closed this as completed Jun 30, 2015
@enebo enebo added this to the Invalid or Duplicate milestone Jul 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants