detect the right root classloader for more cases #2023
Conversation
|
this line is not needed when running the tests via maven since maven puts all the jars in the Thread.currentThread.contextClassLoader but running it in the nexus-server-2.6.x it is needed and from version 2.7.x onwards it uses OSGi and there it is needed as well. since jruby ALWAYS uses the Thread.currentThread.contextClassLoader (beside some edge case where this one is null) this extra line is needed telling jruby to the the classloader which loaded jruby ! |
mkristian
force-pushed
the
detect-root-classloader
branch
from
afeea6d
to
d055432
Compare
mkristian
force-pushed
the
detect-root-classloader
branch
from
d055432
to
a2edea1
Compare
|
I also added the same test case for javax.script.ScriptEngine since with apache-camel this works out of the box for the used OSGi framework. then I found that javax.script.ScriptEngine uses https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/embed/util/SystemPropertyCatcher.java#L137 which is essencially what I propose for JRuby way to detect the parent classloader of the runtime's jruby-class-loader. |
mkristian
force-pushed
the
detect-root-classloader
branch
from
a2edea1
to
54b8ffc
Compare
…by and ScriptingContainer just works * added same test case for JRubyEngineFactory which works without commit b0a9744 * added two more edge cases which would fail normally for JRubyEngineFactory
mkristian
force-pushed
the
detect-root-classloader
branch
from
54b8ffc
to
8d58996
Compare
let the root classloader be the one which is the parent of the JRubyClassloader from the runtime.
RubyInstanceConfig.class.getClassLoader()is actually the right classloader which also contains the kernel. it can be even the theThread.currentThread().getContextClassLoader(). this works quite well for j2ee and osgi environments and from with maven plugins and nexus-plugins.for the commandline execution of jruby the above classloader is null (I guess because jruby is part of the bootclasspath), then the fallback to
Thread.currentThread().getContextClassLoader()will do.in case both classloaders are null there is no difference in the implementation.
this patch I consider actually a bug fix since the usual mantra for using ScritpingContainer for me is
well this patch there is no need to set the right classloader anymore.
@enebo @ratnikov instead of squashing I prepare a handful of small pieces like this