ExceptionReport.tml中的T​​apestry 5.4异常

Question

I've got a question regarding tapestry 5.4. I try to integrate it with tynamo tapestry security and Google App Engine and after some development I started to get these exception when "something" in application is not working. I have written "something" because problem concerns ExceptionPage (as you can see on stacktrace attached below). Has anybody faced such a problem?

Of course I can post some configuration files, but since I have no idea what can cause this exception of error page, I not posing any at the moment.

HTTP ERROR 500

Problem accessing /. Reason:

    org.apache.tapestry5.internal.services.RenderQueueException: Render queue error in SetupRender[core/ExceptionReport:loop_0]: Failure reading parameter 'source' of component core/ExceptionReport:loop_0: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") [at classpath:org/apache/tapestry5/corelib/pages/ExceptionReport.tml, line 110]
Caused by:

org.apache.shiro.subject.ExecutionException: org.apache.tapestry5.internal.services.RenderQueueException: Render queue error in SetupRender[core/ExceptionReport:loop_0]: Failure reading parameter 'source' of component core/ExceptionReport:loop_0: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") [at classpath:org/apache/tapestry5/corelib/pages/ExceptionReport.tml, line 110]
    at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:385)
    at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54)
    at $HttpServletRequestFilter_12a67d391b5c.service(Unknown Source)
    at $HttpServletRequestHandler_12a67d391b5f.service(Unknown Source)
    at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:59)
    at $HttpServletRequestHandler_12a67d391b5f.service(Unknown Source)
    at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62)
    at $HttpServletRequestFilter_12a67d391b59.service(Unknown Source)
    at $HttpServletRequestHandler_12a67d391b5f.service(Unknown Source)
    at org.apache.tapestry5.modules.TapestryModule$1.service(TapestryModule.java:804)
    at $HttpServletRequestHandler_12a67d391b5f.service(Unknown Source)
    at $HttpServletRequestHandler_12a67d391b58.service(Unknown Source)
    at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:166)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.google.appengine.api.socket.dev.DevSocketFilter.doFilter(DevSocketFilter.java:74)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.google.appengine.tools.development.ResponseRewriterFilter.doFilter(ResponseRewriterFilter.java:127)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.google.appengine.tools.development.HeaderVerificationFilter.doFilter(HeaderVerificationFilter.java:34)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.google.appengine.api.blobstore.dev.ServeBlobFilter.doFilter(ServeBlobFilter.java:63)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:125)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.google.appengine.tools.development.DevAppServerModulesFilter.doDirectRequest(DevAppServerModulesFilter.java:366)
    at com.google.appengine.tools.development.DevAppServerModulesFilter.doDirectModuleRequest(DevAppServerModulesFilter.java:349)
    at com.google.appengine.tools.development.DevAppServerModulesFilter.doFilter(DevAppServerModulesFilter.java:116)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
    at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
    at com.google.appengine.tools.development.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:98)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:503)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at org.mortbay.jetty.Server.handle(Server.java:326)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
    at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

Answer 1

The problem is not the exceptionpage but the way Google App Engine (GAE) implements its security policy to restrict spawning new threads. The line:

access denied ("java.lang.RuntimePermission" "modifyThreadGroup")

in your stack trace originates from Java Security Manager for a violation of the policy. While Tynamo's tapestry-security does not invoke new threads, apparently it's not allowed to invoke Callable.call() in GAE. See how the SecurityConfiguration invokes the filter chain after binding the currently executing subject.

Callable is just an interface so it's unnecessary for GAE to prohibit an invocation to it but I suspect it was easier for them to do that than try to block executions of various Executor services that may or may not spawn threads.

However, SecurityConfiguration does not need to use Callable at all. SecurityConfiguration was implemented following Shiro's original AbstractShiroFilter , but one could also manually bind the subject to the currently executing thread, like so:

    ThreadContext.bind(securityManager);
    WebSubject subject = new WebSubject.Builder(securityManager, originalRequest, response).buildWebSubject();
    ThreadContext.bind(subject);
    try {
        // return subject.execute(new Callable<Boolean>() {
        // public Boolean call() throws Exception {
            if (chain == null) return handler.service(request, response);
            else {
                boolean handled = chain.getHandler().service(request, response);
                return handled || handler.service(request, response);
            }
        // }
        // });
    }
    finally {
        ThreadContext.remove(subject);
        ThreadContext.remove();
    }

You could override SecurityConfiguration yourself with a version that operates in the same manner as above. If you want to help, try it and let me know if everything else works. You may run into other issues since GAE can be a fairly restrictive environment for full-fledged Java applications.