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

Jump to bottom

RubyGems 2.4.5 Upgrade Triggers Bug in Java Extension Loading #2336

Closed
bbrowning opened this issue Dec 19, 2014 · 5 comments
Closed

RubyGems 2.4.5 Upgrade Triggers Bug in Java Extension Loading #2336

bbrowning opened this issue Dec 19, 2014 · 5 comments
Milestone
JRuby 1.7.20

Comments

@bbrowning
Copy link
Contributor

RubyGems 2.4.5 has some new logic that sometimes (but not always - depends on what's already loaded or not) expands require statements to absolute paths before passing them on to the original require.

Depending on the state of things, it's possible for a require statement to hit this line of code in RubyGems - https://github.com/rubygems/rubygems/blob/v2.4.5/lib/rubygems/core_ext/kernel_require.rb#L69. That code expands the thing being required to an absolute path before handing it off to the original require logic.

So, when a .jar is required via an absolute path, the logic in ClassExtensionLibrary at

jruby/core/src/main/java/org/jruby/runtime/load/ClassExtensionLibrary.java

Line 67 in 613673a

Class theClass = runtime.getJavaSupport().loadJavaClass(className);
ends up creating the wrong package name and thus cannot load the *Service class for the Java extension. The searchName string passed to ClassExtensionLibrary's tryFind ends up looking something like "/path/to/nokogiri/nokogiri.jar" and it converts that to the class path.to.nokogiri.NokogiriService, which obviously can't be found.

Here's a gist that demonstrates this problem against JRuby 1.7.18-SNAPSHOT - https://gist.github.com/bbrowning/cda2606bd26683ea4831
@bbrowning
Copy link
Contributor Author

CCing @Heading and @enebo - this is the RubyGems 2.4.5 and Nokogiri issue I was working through in IRC earlier today that causes TorqueBox to be unable to run its integration tests against current JRuby 1.7.18-SNAPSHOT builds.

@headius
Copy link
Member

headius commented Dec 19, 2014

@drbrain So here's the situation: in JRuby, extensions have traditionally been a jar with a specially-named class file inside based on the jar's relative path. For example, require 'foo/myext' looks for foo/myext.jar and then for foo.MyextService class within that jar.

The logic above in kernel_require seems to be causing some of those requires to become a full path. So requiring nokogiri's ext through that logic causes the ext to see a non-relative require line and it doesn't load the *Service class.

We have intended to replace the ext mechanism some day, but this is the current situation. It's not quite clear to me why the ext require would end up going through that logic...maybe you can help us understand how that could happen if a library simply requires 'nokogiri' after the gem has been activated.

We're contemplating fixes for this, but in the short term it could be a serious problem.

@headius headius closed this as completed in a0624ee Jan 6, 2015
@enebo
Copy link
Member

enebo commented Jan 30, 2015

This is still causing double loads and I reverted from 1.7.19.

@enebo enebo reopened this Jan 30, 2015
@enebo enebo added this to the JRuby 1.7.20 milestone Jan 30, 2015
@mkristian
Copy link
Member

@enebo do you remember where/how you did see those double loads ?

@headius
Copy link
Member

headius commented Apr 30, 2015

This has been fixed more betterer in recent weeks and RG 2.4.5+ seems to work well now.

@headius headius closed this as completed Apr 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
JRuby 1.7.20
Development

No branches or pull requests
4 participants
@headius @enebo @mkristian @bbrowning