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.

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.