classloader semantics about jruby-gradle-jar-plugin HOT 6 CLOSED

To avoid this behavior we're already using:

ENV['JARS_NO_REQUIRE'] = 'true'
ENV['JBUNDLE_SKIP'] = 'true'
ENV['JARS_SKIP'] = 'true'

In many cases at @lookout where we want to avoid this behavior from jbundler. I'm on the fence as to which approach is the right approach here. What you're proposing would put all the work on loading the included bytecode from a jar like slf4j into the RubyRuntime's classloader wouldn't it?

What happens if there are two RubyRuntime instances being created/executed inside the same JVM? (which is the case with Storm topologies)

I don't have strong opinion either way, I want to make sure jruby-gradle provides the best, most bug-free, experience on JRuby :)

from jruby-gradle-jar-plugin.

from the jruby point of view: each runtime has its own JRubyClassLoader. each require 'my.jar' will be loaded by its runtime into its JRubyClassLoader.

within one jvm one jruby=runtime can use 'slf4j-simple' and the other can use the 'slf4j-log4j' bridge and the third one can use 'logback' - they are all nicely separated per runtime. this is the jruby-classloader semantic.

this example does not work when you put all the jars + jruby into ONE classloader.

and with leafy-metrics and its slf4j-simple it means it can create subtle bugs when using something like logback: it depends on the class-loading which slf4j binding is used (maybe there is warning that more then one bindings are present) or its depends on how the uberjar choose from duplicated classes.

another example is if there is an artifact which uses joda-time-1.6.x and things work standalone, but when bundled with jruby it might (again depends on which classes are picked when bundling the uberjar) blow up jruby since it depends on joda-time-2.x (joda-time 2 is mostly backward compatible to 1.6.x)

so want I propose is to bundle jar-dependencies like gems:

JARS_VENDOR=false JARS_HOME=. GEM_HOME=. GEM_PATH=. gem install rake rspec

take "gems" and "specification" directory and all the directories containing a jar and add them to the userjar.

not sure about jbundler but this does not seems to be relavent since build.gradle does not do anything with the Jarfile - as far I understand.

from jruby-gradle-jar-plugin.

ENV['JBUNDLE_SKIP'] = 'true' is probably not needed unless you bundle jbundler gem as well

`ENV['JARS_SKIP'] = 'true'`` that is not using maven to install jar-dependencies

ENV['JARS_NO_REQUIRE'] = 'true' is needed when the jars are in the same classloader as jruby itself

from jruby-gradle-jar-plugin.

added some intro for https://github.com/mkristian/jruby-mains which explains 'my vision'

from jruby-gradle-jar-plugin.

about the more then one runtime there is subtle issue when running via the regular org.jruby.Main entry-point where the second runtime just uses the jruby-classloader from the first runtime as parent and inherits all its resources: jruby/jruby#2025

again it is easy to construct examples which just fail with such setup - the question is whether those example have practical implication.

IMO jruby just behave as much the same however you execute it.

from jruby-gradle-jar-plugin.

this is done now :)

from jruby-gradle-jar-plugin.