-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JRubyFX application not working when running from jar (works in 1.7, doesn't work in 9k) #4000
Comments
My first guess would be that the |
7e7292e appears to be the commit that introduced Perhaps you can try to reproduce it with 1.7.22 or higher? Definitely seems likely that this is an issue with |
Ok, it does seem like If you could reproduce with Ping @mkristian @kares for suggestions. |
Aha! So it's not a jruby 9k issue. Doing the same thing with jruby-1.7.25 produces a similar, but different error:
Any tips on where this would be passed in? I'm afraid the layers of indirection have me at a loss on how to accomplish this. |
OK, after doing some RTFM'ing, I got more detailed output @headius (9.1.2.0):
I'm hopping on an |
Very strange. Your case seems to be erroring against a classpath URL that contains your full system path. I'm not sure how that would happen. require_relative uses the caller's frame, from Kernel#caller, to determine the source location in the calling method. In my attempt to reproduce the issue, that path appeared to be correct. require_relative then takes that path and uses it to require the file in question. I get to that point in my local test of a hand-made jar. I never get an ENOENT. I am trying to reproduce with your repo now. |
I can reproduce it! Very strange. |
Oh ho, I think I may have a clue! My hand-reproduction was still not failing, so I looked at how JarBootstrapMain boots up. It tries to load the jar-bootstrap.rb file from classpath, but uses a URL without a slash in it: public class JarBootstrapMain {
public static final String JAR_BOOTSTRAP = "classpath:jar-bootstrap.rb";
public static void main(String[] args) {
String[] newArgs = new String[args.length + 1];
newArgs[0] = JAR_BOOTSTRAP;
System.arraycopy(args, 0, newArgs, 1, args.length);
Main.main(newArgs);
}
} This makes the jar-bootstrap.rb file look like a relative path, and it gets expanded somewhere along the way (probably by realpath) with the only path we know about: the current directory. So we get a classpath URL pointing at an absolute system path. This exists in both 1.7 and 9k, but probably only became an issue once we started to use realpath for require_relative. Adding a slash to make these be absolute classpath URLs should fix the issue. |
Well, that's progress...I managed to get past the ENOENT. Unfortunately now I get the other error I was seeing, a LoadError when it actually tries to do the require within the jar. We must go deeper! |
so much ❤️ @headius |
Well 1.7 seems to be working ok without any change, but 9k seems to require this patch to handle diff --git a/core/src/main/java/org/jruby/runtime/load/LibrarySearcher.java b/core/src/main/java/org/jruby/runtime/load/LibrarySearcher.java
index 7ecb6a2..5381fa9 100644
--- a/core/src/main/java/org/jruby/runtime/load/LibrarySearcher.java
+++ b/core/src/main/java/org/jruby/runtime/load/LibrarySearcher.java
@@ -194,6 +194,10 @@ class LibrarySearcher {
// uri: are absolute
return true;
}
+ if (path.startsWith("classpath:/")) {
+ // classpath URLS are absolute if they start with a slash
+ return true;
+ }
return new File(path).isAbsolute();
}
@mkristian @kares Do either of you know why this is needed...or on the flip side, why it doesn't appear to be needed in 1.7? |
This does not appear to be necessary in 1.7, but in 9k if I do not do this then require 'classpath:/somefile' fails to find the file. Stepping through it, I see it skips the absolute path logic that that would have handled it properly and proceeds on to load path logic, which obviously does not find the file.
I went ahead and pushed the additional change. I'm still not certain why it's needed for 9k and not for 1.7. And with your repo...success! I think!
It appears to be booting properly, but I don't know how to use it :-) Optimistically calling this one fixed. |
Thanks @headius. We're past this error and on to another |
Sounds good, thanks! |
* jruby-1_7: Use absolute classpath URL when loading jar-bootstrap. See jruby#4000. Synchronize around getgrgid call. Fixes jruby#4057. Only lock Digest mutex in one place. Explicitly close input stream in CompoundJarURLStreamHandler Write a log message when findClass IOException is caught
Just wanted to report back on this. I was able to workaround the newer issues I stumbled upon and our app is up and running in all envs on I did run across an issue with We'll pin to |
@oreoshake were you able to get past the I created an issue at jruby/jrubyfx#101 but haven't been able to resolve it. Is it related to |
Yes, I commented over on jruby/jrubyfx#101 (comment), but something about the way jrubyfx is checking things on disk has changed - maybe this is more of a jrubyfx bug however. The two lines in question:
and
|
Environment
Provide at least:
jruby -v
) and command line (flags, JRUBY_OPTS, etc)jruby 9.1.2.0 (2.3.0) 2016-05-26 7357c8f Java HotSpot(TM) 64-Bit Server VM 25.60-b23 on 1.8.0_60-b27 +jit [darwin-x86_64]
uname -a
)Darwin Neils-MacBook-Pro-4.local 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
Other relevant info you may wish to add:
Expected Behavior
The test application at https://github.com/oreoshake/jrubyfx-9k-jar-problems should build and run just fine.
$ bundle && rake && java -jar BrakemanPro.jar
should launch the app.Actual Behavior
builds and runs just fine under jruby 1.7.21, but fails under 9k:
But if I unzip the jar and run the file directly, everything is happy:
There's also a flag for compiling code and using that in the jar, but I ran into errors that I can no longer reproduce so it's disabled by default.
Since we're not using much of JRubyFX to build the jar, I assumed the problem lies with some difference between jruby 1.7 and 9k instead of a jrubyfx problem but I could of course be wrong.
EDIT:
I lied, this could also be a jrubyfx thing since I do call the jarify command:
I will file an issue there too.
The text was updated successfully, but these errors were encountered: