-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
Unable to java_import a class on jruby-9.0.0.0.rc1 #3062
Comments
@r6p could you check it's not ~ the same usage pattern as with #3036 (you're manually loading the .jar) |
I get a slightly different message when seeing the context class-loader, but it still fails.
|
in that case we would need a (simple) script to reproduce, including how you're loading the .jar files |
|
@r6p Thank you! I have reproduced locally. |
This may still be a JRuby bug, but it's starting to look like a bug in JBundler (probably some buggy interaction with JRuby 9k). From what I can tell, jbundler simply isn't requiring all the jars in. I added logging to its main bit of logic, in JBundler.require_jars, and all the preconditions it checks fail. As a result, it quietly skips requiring the jars. I think jbundler should probably hard error if it can't bootstrap the jars, or else give some indication that it didn't bootstrap right. I'm not sure why it's behaving this way on 9k but working on 1.7. Reassigning to @mkristian for now since jbundler is his baby. |
my fix for this: --- java_import_orig.rb 2015-07-08 08:43:26.674348905 +0200
+++ java_import.rb 2015-07-08 08:41:52.258718796 +0200
@@ -1,2 +1,3 @@
+java.lang.Thread.current_thread.set_context_class_loader(JRuby.runtime.jruby_class_loader)
require 'jbundler' # JBundler establishes the classpath
java_import 'org.apache.hadoop.hbase.protobuf.ProtobufUtil' which leads to
@headius will be later on irc to dicuss this context-classloader problem |
@r6p could you verify my fix on your side ? since you did try something similar before |
still investigating - since if I execute the code manually it will not raise the error but the moment the |
my mystery resolved: the code I used was from newer version of the libraries. the current JRuby situation is: whatever runs inside an OSGi container works with JRuby. if you need to set the context classloader in the OSGi case you also need to do this on JRuby see also last code snippet here (karaf is meta osgi container or so) https://dzone.com/articles/apache-karaf-meets-apache |
I reproduced the problem using JBundler but it also occurs with LockJar. But using your code above, i.e java.lang.Thread.current_thread.set_context_class_loader(JRuby.runtime.jruby_class_loader), I can no longer reproduce. I am interested to know how the class-loading issues you describe affect Jruby code that is running in a Java context, i.e. compiled with jrubyc. |
so apparently when org.apache.hadoop.hbase.protobuf.ProtobufUtil gets loaded it loads a file 'hbase-default.xml' via the for me the savest code would be: ocl = java.lang.Thread.current_thread.context_class_loader
begin do
java.lang.Thread.current_thread.set_context_class_loader(JRuby.runtime.jruby_class_loader)
java_import 'org.apache.hadoop.hbase.protobuf.ProtobufUtil'
ensure
java.lang.Thread.current_thread.context_class_loader = ocl
end which should work for any java context you code runs in and independent to your jruby version - 1.7.x or 9k |
I would hate to have to pepper my code with this type of fallback class loader logic. I guess I'll have to try both scenarios to ensure when, java.lang.Thread.current_thread.set_context_class_loader(JRuby.runtime.jruby_class_loader), is truly needed. As it may only be needed when running from a context that is principally Jruby app based and not Java app based. |
fixed via 7d3bc47 |
Verified that with jruby-head from the evening of 7/17, that this is now fixed. Thanks @mkristian! |
java_import 'org.apache.hadoop.hbase.protobuf.ProtobufUtil' works fine on jruby-1.7.19 but not on jruby-9.0.0.0.rc1, could this be due to new class loading behavior?
The text was updated successfully, but these errors were encountered: