ExceptionReport.tml中的Tapestry 5.4异常

Question

我有一个关于tapestry 5.4的问题。我尝试将它与tynamo tapestry安全和Google App Engine集成，经过一些开发后，当应用程序中的“某些东西”不工作时，我开始得到这些异常。我写了“一些东西”，因为问题与ExceptionPage有关(你可以在下面的堆栈跟踪中看到)。有没有人遇到过这样的问题？

当然，我可以发布一些配置文件，但由于我不知道是什么导致了这个错误页面的异常，所以我现在不会提出任何问题。

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

问题不在于异常页面，而在于Google App Engine (GAE)实现其安全策略以限制产生新线程的方式。这行代码：

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

在堆栈中，跟踪源自违反策略的Java Security Manager。虽然Tynamo的tapestry-security不会调用新线程，但显然它不允许在GAE中调用Callable.call()。了解SecurityConfiguration如何在绑定当前执行的主题之后调用筛选器链。

Callable只是一个接口，所以GAE没有必要禁止对它的调用，但我怀疑对他们来说，这样做要比阻止可能会或可能不会产生线程的各种Executor服务的执行要容易得多。

然而，SecurityConfiguration 根本不需要使用。SecurityConfiguration是在Shiro最初的AbstractShiroFilter之后实现的，但也可以手动将主题绑定到当前执行的线程，如下所示：

    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();
    }

您可以使用与上述操作方式相同的版本来覆盖SecurityConfiguration。如果你想帮忙，试一试，让我知道其他一切是否正常。您可能会遇到其他问题，因为对于成熟的Java应用程序来说，GAE可能是一个相当严格的环境。