jruby-openssl
jruby-openssl copied to clipboard
jruby
maybe we need some option to not load any jars
... to allow users to suply BC jars from somewhere in the CP
:+1: In Puppet Labs' Puppet Server product, we have this same need - to supply our own newer BC jar because we have other code in our app that needs a newer version than what is bundled in JRuby by default. We're currently working around this by explicitly requiring 'jar-dependencies' and setting the JARS_NO_REQUIRE environment variable to "true" since later jopenssl versions don't require 'jar-dependencies' automatically. We'd like to have a more direct way to specify that jars not get loaded which doesn't involve having to exercise 'jar-dependencies' directly. What actually does the jar loading is an implementation detail that we don't really care about directly as we're mostly concerned with just turning it off.
jar-dependencies should be used to load the jars if the gem is available -
it comes as default gem with jruby-1.7.16+ or so. otherwise the control of
those jars depends on whether I require 'jar-dependencies' before
loading jopenssl or not.
think it makes sense even with jar-dependencies around, since jruby-openssl is kind of a must gem in all thinkable (and non-thinkable) use-cases due how the Ruby the eco-system relies on require 'openssl'
actually have an embed use-case of my own starting several Rubies (JRuby is custom built and gems are packed up for isolation) ... lately I found myself wanting to experiment with a custom built BC jar. think I'll go for a (unofficial) -Djruby.openssl.load.jars=false system property
jar-dependencies already has a way to pick jar versions and the next release will have a way to tell not to load jars - i.e. decalre them provided.
my point here is not so much the extra system property but that the gem ignores jar-dependencies when the gem is available (like via jruby itself).
and with 9k there will be a similar situation with snakeyaml jar which is used for psych (via require 'yaml') so we need a common way to load or not to load such jars. dito with jline-2.11jar from readline.
my point here is not so much the extra system property but that the gem ignores jar-dependencies when the gem is available (like via jruby itself).
we decided previously not to load jar-dependencies explicitly since that is something the user should do, so I guess that is what you're referring to (otherwise we're using it when it's already loaded).
and with 9k there will be a similar situation with snakeyaml jar which is used for psych (via require 'yaml') so we need a common way to load or not to load such jars. dito with jline-2.11jar from readline.
understand the concern to have a common API ... and we do have a great one (jar-dependencies) but I'm against forcing a require 'jar_dependencies' on require 'openssl' the user should be smart enough to do so when he's about to start changing which .jars to use
well, let's wait until not requiring jar-dependencies really loads two different version of BC into the jruby-classloader.
FYI readline and psych do require jar-dependencies before loading their jars. with Jars.lock you can just declare you jars there and on first require_jar it loads all those jars or/and marks them as "loaded". so I guess I understood the decision differently - regarding the post_install hook when installing jars. but never mind - I will keep my mouth shut since I expressed my point already.
BTW at lookout we have an application which shares quite big number of jar between a java application which launches a rack application sharing basically half the dropwizards framework. jar-dependencies will allow to avoid jar with different version in the same classloader hierarchy.