[jruby-user] "org.jruby.rack.RackInitializationException: IO error -- rack" on Tomcat 5.5

[Albert Ramstedt]

Hi.

I am trying to deploy a war i made with warbler 0.9.9. When i drop it
into tomcat i get a wierd error in the logs:

SEVERE: Warning: error application could not be initialized
org.jruby.rack.RackInitializationException: IO error -- rack
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/jruby/rack.rb:7
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/jruby/rack.rb:7:in
`require'
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/rack/handler/servlet.rb:7
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/rack/handler/servlet.rb:1:in
`require'
from <script>:1

.. and further down:

Caused by: org.jruby.exceptions.RaiseException: IO error -- rack
Caused by: java.lang.StringIndexOutOfBoundsException: String index out
of range: -1
at java.lang.String.substring(String.java:1932)
at java.lang.String.substring(String.java:1905)

I have tried adding the rack gem to the gems, and have tried both the
jruby 1.1.1 and 1.1.2 jars.

What could be the problem?

full backtrace:

org.jruby.rack.RackInitializationException: IO error -- rack
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/jruby/rack.rb:7
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/jruby/rack.rb:7:in
`require'
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/rack/handler/servlet.rb:7
from file:/var/lib/tomcat5.5/webapps/auktion/WEB-INF/lib/jruby-rack-0.9.jar!/rack/handler/servlet.rb:1:in
`require'
from <script>:1

at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:85)
at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:144)
at org.jruby.rack.DefaultRackApplicationFactory.newErrorApplication(DefaultRackApplicationFactory.java:99)
at org.jruby.rack.DefaultRackApplicationFactory.init(DefaultRackApplicationFactory.java:39)
at org.jruby.rack.PoolingRackApplicationFactory.init(PoolingRackApplicationFactory.java:53)
at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:38)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3764)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:744)
at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:144)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:738)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1206)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:293)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1306)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1570)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1579)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1559)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.jruby.exceptions.RaiseException: IO error -- rack
Caused by: java.lang.StringIndexOutOfBoundsException: String index out
of range: -1
at java.lang.String.substring(String.java:1932)
at java.lang.String.substring(String.java:1905)
at org.jruby.RubyFile.expand_path(RubyFile.java:1000)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jruby.internal.runtime.methods.ReflectedJavaMethod.call(ReflectedJavaMethod.java:141)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:233)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:142)
at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:141)
at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:336)
at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:101)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:67)
at org.jruby.ast.RootNode.interpret(RootNode.java:126)
at org.jruby.Ruby.loadFile(Ruby.java:2018)
at org.jruby.runtime.load.ExternalScript.load(ExternalScript.java:58)
at org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:320)
at org.jruby.runtime.load.LoadService.require(LoadService.java:346)
at org.jruby.RubyKernel.require(RubyKernel.java:769)
at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jruby.internal.runtime.methods.ReflectedJavaMethod.call(ReflectedJavaMethod.java:141)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:233)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:142)
at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:141)
at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:336)
at org.jruby.ast.FCallOneArgNode.interpret(FCallOneArgNode.java:36)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:101)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:67)
at org.jruby.ast.RootNode.interpret(RootNode.java:126)
at org.jruby.Ruby.loadFile(Ruby.java:2018)
at org.jruby.runtime.load.ExternalScript.load(ExternalScript.java:58)
at org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:320)
at org.jruby.runtime.load.LoadService.require(LoadService.java:346)
at org.jruby.RubyKernel.require(RubyKernel.java:769)
at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jruby.internal.runtime.methods.ReflectedJavaMethod.call(ReflectedJavaMethod.java:141)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:233)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:142)
at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:141)
at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:336)
at org.jruby.ast.FCallOneArgNode.interpret(FCallOneArgNode.java:36)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:101)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:67)
at org.jruby.ast.RootNode.interpret(RootNode.java:126)
at org.jruby.Ruby.loadFile(Ruby.java:2018)
at org.jruby.runtime.load.ExternalScript.load(ExternalScript.java:58)
at org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:320)
at org.jruby.runtime.load.LoadService.require(LoadService.java:346)
at org.jruby.RubyKernel.require(RubyKernel.java:769)
at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jruby.internal.runtime.methods.ReflectedJavaMethod.call(ReflectedJavaMethod.java:141)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:233)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:142)
at org.jruby.runtime.CallSite$InlineCachingCallSite.cacheAndCall(CallSite.java:141)
at org.jruby.runtime.CallSite$InlineCachingCallSite.call(CallSite.java:336)
at org.jruby.ast.FCallOneArgNode.interpret(FCallOneArgNode.java:36)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:101)
at org.jruby.ast.RootNode.interpret(RootNode.java:126)
at org.jruby.Ruby.evalScriptlet(Ruby.java:231)
at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:82)
at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:144)
at org.jruby.rack.DefaultRackApplicationFactory.newErrorApplication(DefaultRackApplicationFactory.java:99)
at org.jruby.rack.DefaultRackApplicationFactory.init(DefaultRackApplicationFactory.java:39)
at org.jruby.rack.PoolingRackApplicationFactory.init(PoolingRackApplicationFactory.java:53)
at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:38)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3764)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4216)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:744)
at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:144)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:738)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1206)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:293)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1306)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1570)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1579)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1559)
at java.lang.Thread.run(Thread.java:619)

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Nick Sieger]

Hi Albert, did you ever find a solution to this issue?

/Nick

[Albert Ramstedt]

No, sadly I did not. My fix was to use glassfish instead, some people
say using tomcat 6 works for them.

Albert

[Michael Pitman]

Wow - I'm dredging up a really old stack trace here, but I've got this error at the moment trying to deploy to Tomcat 6.0.18. The application works fine with Jetty 6.1.1.

My machine has the following:
Ubuntu 8.10, amd64
64 bit jdk 1.6.0u10
JRuby 1.1.6
Rails 2.1.2
Tomcat 6.0.18
Warbler 0.9.12 with jruby-rack 0.9.3

Did anyone else encounter the problem and figure it out? I'd appreciate some help! It looks like it's dying on the line "require rack" - which is the first time it's looking for a ruby file in the root of a jar (the jruby-rack jar).

BTW - jruby-rack does not pass unit tests on my machine either - it looks like some problems with overrides of servlet classes.

Thanks,

Michael

[Michael Pitman]

Well, answering my own question here in the hopes of helping others.

It seems that the default security policies for the tomcat6 package for
Ubuntu don't allow newly deployed applications to read their own files!

I edited /etc/tomcat6/policy.d/50local.policy to allow all permissions
on the deployment directory, and everything started working. The entry I
added was:

grant codeBase "file:${catalina.base}/webapps/-" {
permission java.security.AllPermission;
};

The stack trace below showing a problem with require was a bit of a red
herring - there's a boolean "isAbsoluteWithFilePrefix" defined at the
top of RubyFile.expand_path(), then referenced at the end of the method.
In the code in the middle, the prefix gets stripped if you don't have
the appropriate permissions (actually it's if System.getParameter()
throws a security exception). The resulting file path doesn't have the
file: prefix any more, so throws the exception below.

It would probably be nice to issue a warning if someone is trying to run
without sufficient security (ie Ruby.isSecurityRestricted()). I'm sure
that some things run OK, so it's not worth just aborting, but my app
really didn't seem to like it...

Regards,

Michael

[Charles Oliver Nutter]

This is a good find. Can you add something to the wiki?

I guess we've always figured there might be servers that restrict
security in such a way that limits how we deploy WAR stuff right now. Is
there any discussion or recommendation on how apps should deal with
this? Modifying the security policy works, but I'm predicting some time
in the future when some large company has Tomcat 6 in production and
their production staff refuses to adjust security policies. What do we
do then?

Any research you can do here would be a great help :)

- Charlie

[Nick Sieger]

On Tue, Jan 27, 2009 at 9:05 AM, Charles Oliver Nutter
<charles...@sun.com> wrote:
> This is a good find. Can you add something to the wiki?
>
> I guess we've always figured there might be servers that restrict security
> in such a way that limits how we deploy WAR stuff right now. Is there any
> discussion or recommendation on how apps should deal with this? Modifying
> the security policy works, but I'm predicting some time in the future when
> some large company has Tomcat 6 in production and their production staff
> refuses to adjust security policies. What do we do then?
>
> Any research you can do here would be a great help :)

One thought is that it's probably possible to read the files with
ServletContext.getResource/getResourceAsStream, except that we'd have
to change the way files are read using load/require. Perhaps a
pluggable load service where we shuttle load/require requests through
these APIs rather than the normal filesystem APIs would help.

/Nick

[Charles Oliver Nutter]

Nick Sieger wrote:
> On Tue, Jan 27, 2009 at 9:05 AM, Charles Oliver Nutter
> <charles...@sun.com> wrote:
>> This is a good find. Can you add something to the wiki?
>>
>> I guess we've always figured there might be servers that restrict security
>> in such a way that limits how we deploy WAR stuff right now. Is there any
>> discussion or recommendation on how apps should deal with this? Modifying
>> the security policy works, but I'm predicting some time in the future when
>> some large company has Tomcat 6 in production and their production staff
>> refuses to adjust security policies. What do we do then?
>>
>> Any research you can do here would be a great help :)
>
> One thought is that it's probably possible to read the files with
> ServletContext.getResource/getResourceAsStream, except that we'd have
> to change the way files are read using load/require. Perhaps a
> pluggable load service where we shuttle load/require requests through
> these APIs rather than the normal filesystem APIs would help.

That's not a bad idea; Ola already wired in some logic whereby they can
provide their own loadservice implementation in Mingle that knows how to
load encrypted files. Loading files from a secured location via other
means (like getResource) is probably the same sort of thing.

- Charlie