|
The context of finding this problem is that the product I work on, Mingle, is a Rails app running on JRuby. Currently we are on JRuby 1.6.8. Recently we wanted to upgrade to 1.7.2 but we encountered a strange problem that we became stuck on.
Our use case is extremely convoluted and I won't even attempt to explain it fully here. At a high level, our Rails app creates a ScriptingContainer and boots another instance of Rails inside of it in order to have a clean Ruby runtime to perform DB migrations on a different set of tables than the main app. In any case, I was able to pare the issue we're experiencing down to a simple test case that throws the same error. Hopefully any insights you can offer for this simple case might help us figure out our issue.
Here is the snippet of our production Ruby code that creates the scripting container if that helps:
container = org.jruby.embed.ScriptingContainer.new(org::jruby::embed::LocalContextScope::THREADSAFE)
container.setEnvironment(ENV)
container.setLoadPaths($![]()
container.runScriptlet("....require File.join(RAILS_ROOT, 'config', 'boot')...")
After a lot of debugging, we discovered that $: in our app contains an entry that points to the ruby inside the jruby jar: jruby-complete-1.7.2.jar!/META-INF/jruby.home/lib/ruby/1.8. When we stripped it out, we can successfully require and use FileUtils. However, when this entry is included, we get an exception while trying to require 'fileutils':
org.jruby.exceptions.RaiseException: (NameError) undefined method 'options_of' for class '#<Class:0x15880543>'
Since that's pretty generic, we put some debugging into the ruby file lib/ruby/1.8/fileutils.rb in the jruby source and built our own 1.7.2 complete jar. The problem seems to be that FileUtils creates a constant called METHODS around line 1519. When it breaks with the above exception, the call to singleton_methods returns symbols instead of strings and so the subtraction of the strings doesn't remove options_of and it blows up. I don't know how much of that actually matters. I imagine that's just the first thing that breaks but that the Ruby runtime inside our ScriptingContainer is in a bad state to begin with. However, the exact same execution worked fine in 1.6.8.
Sorry for the long description but we spent a few days researching it and we couldn't find a way to workaround the problem so we're blocked on the upgrade for now. Hopefully you can shed some light on the issue.
|
