Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: JRuby 0.9.1, JRuby 0.9.2
-
Fix Version/s: JRuby 0.9.9
-
Component/s: Java Integration
-
Labels:None
-
Environment:Debian GNU/Linux, kernel 2.6.16.16, i686, GlassFish V2 b20
-
Number of attachments :
Description
Initial setup:
GlassFish domain is located at ${domain}.
jruby.jar is located in ${domain}/lib/ext
Web application (WAR file), which contains a JAR file (later referred to as r.jar) in WEB-INF/lib which contains some ruby modules, is deployed into this domain.
When the web application tries to execute some external ruby script (using absolute path, passing it to org.jruby.Main.run() method), and the script requires a ruby module which is located in r.jar, JRuby engine cannot resolve this module. However, if jruby.jar is located in the WEB-INF/lib of the same web application, JRuby can load the required module.
NB: org.jruby.Main.run() is used because I need to hijack stdin/stdout/stderr of the script (I couldn't find how to do it using BSF)
I've noticed this before when browsing the source code. Perhaps wherever Class.forName is used, the 3-arg version of Class.forName should be used instead with the Thread context class loader (if it's available). This would make embedding in managed environments or classloader hierarchies possible.