This is a bug. We walk the load paths (like classpath in Java, but
for n directories to search for .rb files in Ruby) and in the loop we
mutate the name during processing one of those directories:
if (name.startsWith(entry)) {
name = name.substring(entry.length());
}
For each loadpath onward we are using a stripped out name from the
processing of a previous loadpath element. Then by the time we exit
the loop a safe assumption that name is not zero length has been
violated.
I will correct this on master (running our tests against this now).
Thanks for your detailed attempt at breaking this down. It made is
really easy to see the issue even though I don't have pig downloaded
and a replicated test handy.
-Tom
On Thu, Mar 22, 2012 at 8:34 PM, Jonathan Coveney <jcove...@gmail.com> wrote:
> This is JRuby 1.6.7. I was getting a string length error when doing a
> require in 1.9 mode. It was pretty weird to track down and I'm not sure how
> to replicated it outside of my pretty specific case, but I was hoping you
> could
> a) help replicate it
> b) see if this needs to be fixed
> c) give me a workaround pending a newer version
>
> I'm going to be quite detailed, because I'm not sure where the fix should
> go, and if there should be a workaround. I'd really love your help, as I
> want to use 1.9 mode, but forking the codebase isn't really an option...
>
> the issue is with this function:
> protected LoadServiceResource findFileInClasspath(String name)
>
> in LoadService.java
>
> In my case, when it does:
>
> for (int i = 0; i < loadPath.size(); i++) {
>
> and goes through the entries on the loadPath (what is setting the loadPath,
> btw? is it the JVM?), it's getting:
>
> RubyString entryString = loadPath.eltInternal(i).convertToString();
>
> However, the file being required is the same as one of the entries...so when
> it gets to the following:
>
> if (name.startsWith(entry)) {
> name = name.substring(entry.length());
> }
>
> name is being set to ''
>
> Thus, when the following is called:
>
> if (name.charAt(0) == '/' || (name.length() > 1 && name.charAt(1) == ':'))
> return null;
>
> it's getting an error.
>
> So, for more context (though like I said, this error is pretty specific):
>
> I'm running another project as such:
>
> java -cp pig.jar:/Users/jcoveney/Downloads/jruby-1.6.7/lib/jruby.jar
> org.apache.pig.Main -x local
>
> within that project, eventually via reflection a class is instantiated which
> has a ScriptingContainer, as such:
>
> protected static final ScriptingContainer rubyEngine;
>
> static {
> rubyEngine = new ScriptingContainer(LocalContextScope.SINGLETHREAD,
> LocalVariableBehavior.PERSISTENT);
> rubyEngine.setCompatVersion(CompatVersion.RUBY1_9);
> }
>
> then, eventually, a script is instantiated as such:
>
> rubyEngine.runScriptlet(getScriptAsStream(path), path);
>
> where path is a file called 'pigudf.rb'
>
> the header of this file is:
>
> throw "pigudf.rb only works under JRuby!" unless RUBY_PLATFORM=="java"
> require 'jruby'
> require 'pig.jar'
> org.apache.pig.scripting.jruby.PigJrubyLibrary.new.load(JRuby.runtime,
> false)
>
> The issue is with the "require 'pig.jar'" piece. Eventually, it gets to the
> point where the name of the resource being requested is pig.jar, but pig.jar
> is also on the classpath...so it sets name='', and bag, issue.
>
> I changed the line to:
>
> if (name.length() > 0 && name.charAt(0) == '/' || (name.length() > 1 &&
> name.charAt(1) == ':')) return null;
>
> and everything worked perfectly. I don't know JRuby well enough at this
> point to know whether or not that would prevent anything from
> happening...perhaps in this case, it should attempt to load the jar file,
> since it is in fact on the classpath?
>
> Your help is appreciated! Especially how to workaround this (and ideally any
> workarounds would be on the backend and not require the user to require
> something crazy, but I'll deal with it as it comes)
>
--
blog: http://blog.enebo.com twitter: tom_enebo
mail: tom.en...@gmail.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
