better jruby.home detection on IBM WAS

[kares]

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

[kares]

in case you guys decide to merge this in it would be fine to get it on 1_6 as well // cc @headius

[BanzaiMan]

I merged this to the master as bec227e.