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

Comments

Projects
None yet
5 participants
@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

This comment has been minimized.

Show comment
Hide comment
@headius

headius Aug 18, 2015

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@mkristian

mkristian Aug 19, 2015

Member
Member

mkristian commented Aug 19, 2015

@CeesZ

This comment has been minimized.

Show comment
Hide comment
@CeesZ

CeesZ 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

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

This comment has been minimized.

Show comment
Hide comment
@headius

headius Sep 4, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@mkristian

mkristian Sep 4, 2015

Member
Member

mkristian commented Sep 4, 2015

@CeesZ

This comment has been minimized.

Show comment
Hide comment
@CeesZ

CeesZ 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

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

This comment has been minimized.

Show comment
Hide comment
@mkristian

mkristian Sep 14, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@mkristian

mkristian Sep 14, 2015

Member

@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

Member

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