jruby/jruby — pull request #123 by kares (2012-02-09 20:14:07+00:00)
Title: better jruby.home detection on IBM WAS

currently `config.getJRubyHome()` on WAS ends up being the fall-back */tmp* dir (e.g. when deploying a .war)
this is probably due to a slightly non-standard `getResource()` IBM Java behavior - it seems to always return `null` for jar "dirs" but works if you ask for a jar "file" entry.

sample return values :

getResource("/META-INF/jruby.home") returns a null

getResource("/META-INF/jruby.home/bin/jrubyc") returns :
wsjar:file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/debianNode01Cell/rails31_war.ear/rails31.war/WEB-INF/lib/jruby-stdlib-1.6.7.dev.jar!/META-INF/jruby.home/bin/jrubyc

getResource("/META-INF/jruby.home/bin/jrubyc").getProtocol() would return "wsjar"

and the location (if it passed the if) would have been :
file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/debianNode01Cell/rails31_war.ear/rails31.war/WEB-INF/lib/jruby-stdlib-1.6.7.dev.jar!/META-INF/jruby.home/bin/jrubyc

I think it's fine that we do not pass `resource.getProtocol().equals("jar")` since than the `location` would not have been set to `location = "classpath:/META-INF/jruby.home";` but end up as a `file:/...` path (that would need to be stripped from "/bin/jrubyc") but since we can not walk URLs as a FS anyway `classpath:/META-INF/jruby.home` seems fine and is working fine (with the LoadService).

we've been using a "hack" (if `JRuby.runtime.instance_config.jruby_home == tmpdir`) in **jruby-rack** to fix the `$LOAD_PATH` but if **jruby** correctly detected it's home it would not have been necessary ...

tested environment :

WebSphere Application Server 8.0.0.1
Host Operating System is Linux, version 2.6.32-5-686
Java version = 1.6.0, Java Compiler = j9jit26, Java VM name = IBM J9 VM