We recently upgraded from JRuby 1.5.6 to 1.7.3 and I’ve run into an
issue that I hope someone on this list may be able to shed some light
on.
I am working an a multi-threaded Java application which is built on
OSGi. As part of the upgrade to 1.7.3 I now have my jruby-complete.jar
running as an OSGi bundle and I no longer have to bundle a jruby.jar
file in with my OSGi bundle that uses JRuby. I have also switched from
using ScriptingContainer to OSGiScriptingContainer.
I am also trying to transition from using the THREADSAFE
LocalContextScope to CONCURRENT as I need a single Ruby runtime but want
the receivers associated with different threads to be maintained as
thread local variables.
I first ran into JRuby issue JRUBY-6265. That issue describes an
scenario where paths that have been added to the ScriptingContainer load
path are not added to the Ruby runtime load path when LocalContextScope
is set to SINGLETON (as opposed to SINGLETHREAD). I found that this is
also true when using CONCURRENT.
I have been able to get around this issue by using the work-around
described in JRUBY-6265 by issuing ScriptingContainer.runScriplet("$: <<
‘/desired/path’;");
The next issue I ran into was with the Gem path. We re-package the
jruby-complete.jar file with several Ruby gems that our application
requires. When using THREADSAFE the Gem path is built correctly and
JRuby is able to find the Gems bundled into the jruby-complete.jar file.
However, when using CONCURRENT, the Gems are not found.
When using THREADSAFE Gem path looks like:
["/opt/application/lib/configuration/org.eclipse.osgi/bundles/3/1/.cp/META-INF/jruby.home/lib/ruby/gems/shared",
“/.gem/jruby/1.9”]
When using CONCURRENT Gem path looks like:
[“classpath:/META-INF/jruby.home/lib/ruby/gems/shared”,
“/.gem/jruby/1.9”]
Has anyone come across a similar issue?
Best regards,
Mike