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

Question

我有一個關於掛毯5.4的問題。 我嘗試將其與tynamo掛毯安全性和Google App Engine集成在一起，經過一些開發，當應用程序中的“某些內容”不起作用時，我開始遇到這些異常。 我寫了“東西”，因為問題涉及ExceptionPage（如您在下面所附的stacktrace上看到的）。 有人遇到過這樣的問題嗎？

當然，我可以發布一些配置文件，但是由於我不知道是什么原因導致此錯誤頁面異常，所以我暫時不擺姿勢。

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 完全不需要使用Callable。 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。 如果您想提供幫助，請嘗試一下，讓我知道其他所有操作是否都有效。 由於GAE對於成熟的Java應用程序可能是一個相當嚴格的環境，因此您可能會遇到其他問題。