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

RubyGems 2.4.5 Upgrade Triggers Bug in Java Extension Loading #2336

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

Comments

Projects
None yet
4 participants
@bbrowning
Copy link
Contributor

commented Dec 19, 2014

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

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

This comment has been minimized.

Copy link
Contributor Author

commented Dec 19, 2014

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

This comment has been minimized.

Copy link
Member

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 in a0624ee Jan 6, 2015

@enebo

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Apr 13, 2015

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

@headius

This comment has been minimized.

Copy link
Member

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 Apr 30, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.