Skip to content
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

Initial $LOAD_PATH depends on JRUBY_HOME in jruby-complete-9.0.0.0 #3257

Closed
CeesZ opened this issue Aug 16, 2015 · 8 comments
Closed

Initial $LOAD_PATH depends on JRUBY_HOME in jruby-complete-9.0.0.0 #3257

CeesZ opened this issue Aug 16, 2015 · 8 comments
Labels
Milestone

Comments

@CeesZ
Copy link

@CeesZ CeesZ commented Aug 16, 2015

The default $LOAD_PATH for jruby-complete-9.0.0.0 depends on the environment variable JRUBY_HOME
In my opinion that is not desirable if you are running an application in a JAR, when you
need the initial $LOAD_PATH for access to the standard libraries and do not want
(accidental) interference with the libraries from outside the JAR.
If an application wants to take note of JRUBY_HOME it should do so by inspecting the
environment variable itself.
jruby-complete-1.7.19 did NOT depend on JRUBY_HOME, see following example:

C:\Projects\XLibriz\lib\java>CD C:\Projects\XLibriz\lib\java

SET JRUBY_HOME=C:\jruby-1.7.19

java -jar jruby-complete-1.7.19.jar -e "puts $LOAD_PATH.join("\n");"
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/1.9/site_ruby
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/shared
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/1.9

java -jar jruby-complete-9.0.0.0.jar -e "puts $LOAD_PATH.join("\n");"
Warning: JRuby home "C:/jruby-1.7.19" does not exist, using C:\Users\user\AppData\Local\Temp
C:/Users/user/AppData/Local/Temp/lib/ruby/2.2/site_ruby
C:/Users/user/AppData/Local/Temp/lib/ruby/stdlib

SET JRUBY_HOME=C:\Data (existing directory, no Ruby files)

java -jar jruby-complete-1.7.19.jar -e "puts $LOAD_PATH.join("\n");"
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/1.9/site_ruby
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/shared
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/1.9

java -jar jruby-complete-9.0.0.0.jar -e "puts $LOAD_PATH.join("\n");"
C:/Data/lib/ruby/2.2/site_ruby
C:/Data/lib/ruby/stdlib

SET JRUBY_HOME=

java -jar jruby-complete-1.7.19.jar -e "puts $LOAD_PATH.join("\n");"
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/1.9/site_ruby
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/shared
file:/C:/Projects/jruby-complete-1.7.19.jar!/META-INF/jruby.home/lib/ruby/1.9

java -jar jruby-complete-9.0.0.0.jar -e "puts $LOAD_PATH.join("\n");"
uri:classloader:/META-INF/jruby.home/lib/ruby/2.2/site_ruby
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib

@rtyler rtyler added the JRuby 9000 label Aug 17, 2015
@headius
Copy link
Member

@headius headius commented Aug 18, 2015

So are you proposing that the jruby-complete.jar should ignore JRUBY_HOME? And it sounds like that was the case in 1.7.19 and earlier?

@mkristian
Copy link
Member

@mkristian mkristian commented Aug 19, 2015

@CeesZ
Copy link
Author

@CeesZ CeesZ commented Aug 20, 2015

Yes, exactly.

I use JRUBY-COMPLETE as the base for a standalone application jar, which should run on any computer with the right operating system.

Users should not have to worry about the environment it runs in. In a sense the ‘complete’ part of the name says it all. In cases where JRUBY_HOME is needed, it is probably better to use JRUBY.

But maybe others have different use cases in favor of the use of JRUBY_HOME in JRUBY-COMPLETE

@headius
Copy link
Member

@headius headius commented Sep 4, 2015

I have one idea how to do this...if we set a different main for the complete jar versus the jruby.jar we put into a distribution, we'd know how it was launched. They'd essentially do the same thing, but when running from jar main it wouldn't look at environment variables...only properties.

The other option would be to never look at environment vars in the Java code, and rely on the launchers to do it. Most people who use the env vars use our bin/jruby.bash or the native equivalent, which could just take those environment variables and put them in the right properties.

@mkristian
Copy link
Member

@mkristian mkristian commented Sep 4, 2015

@CeesZ
Copy link
Author

@CeesZ CeesZ commented Sep 13, 2015

I do not really understand the issue with jruby-jars.gem (probably because I never used it), but I would favor a solution where the default for jruby-complete is to ignore JRUBY_HOME. The solution as proposed by headius - to set a different main for the complete jar - seems a good way to achieve this.
Apropos of other actions depending on whether running from the "filesystem" or running from a "jar", it would be nice to have a more elegant way to determine this than by inspecting if __FILE__ starts with uri:classloader or contains .jar! as I do at the moment. Maybe it exists and I missed it.
==Cees

@mkristian
Copy link
Member

@mkristian mkristian commented Sep 14, 2015

I am on it now. but the different main is tricky since the we have several distributions:

  • tar.gz or zip binary distribution
  • modular maven artifact
  • complete/shaded maven artifact for easy command line execution and it is also an OSGi bundle
  • jruby-jars gem which is kind of a mix for all the above three

the last three use the same jars from a java point of view. they are only differently packed. one jar or two jars or many jars.

and there is already a way to determine whether we run from classpath which contains META-INF/jruby.home or so that spawing a new jruby process works. here switching the main method would need to follow as well.

so what I am about to do is give preference to META-INF/jruby.home instead of using the environment JRUBY_HOME.

the other issue is not clear to me: the best would be to look at JRuby.runtime.instance_config.jruby_home
to see if the stdlib is on classpath or from filesystem.

or if you code runs from within a jar you can look at Dir.pwd and check if this startsWith uri:classloader: which can be useful for example setting up a log file somewhere outside the application "directory"

probably a check on a given file would help as well. let's see.

@mkristian mkristian closed this in f25d0a8 Sep 14, 2015
@mkristian
Copy link
Member

@mkristian mkristian commented Sep 14, 2015

@headius that the ScriptingContainer behaves differently, i.e. gives first preference to JRUBY_HOME is something which we do in jruby-1.7.x but I would go for a more uniform solution and remove those code lines: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L268

@enebo enebo added this to the JRuby 9.0.2.0 milestone Oct 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.