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

detect the right root classloader for more cases #2023

wants to merge 2 commits into from


Copy link

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 the Thread.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

sc = new ScriptingContainer();
sc.setClassLoader( ScriptingContainer.class.getClassLoader() );

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

@mkristian mkristian mentioned this pull request Oct 9, 2014
Copy link
Member Author

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 !

Copy link
Member Author

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

which is essencially what I propose for JRuby way to detect the parent classloader of the runtime's jruby-class-loader.

…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

2 participants