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

Closed
wants to merge 2 commits into from

Conversation

mkristian
Copy link
Member

@mkristian mkristian commented Oct 6, 2014

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
@mkristian
Copy link
Member Author

mkristian commented Oct 14, 2014

https://github.com/sonatype/nexus-ruby-support/blob/1.4.4/nexus-ruby-tools/src/main/java/org/sonatype/nexus/ruby/DefaultRubygemsGateway.java#L39

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
Copy link
Member Author

mkristian commented Nov 3, 2014

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 mkristian force-pushed the detect-root-classloader branch from a2edea1 to 54b8ffc Compare Nov 5, 2014
…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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants