[jira] [Commented] (TAP5-986) sendError in onActivate / Tapestry error dispatching

["Kalle Korhonen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466369#comment-13466369 ] 

Kalle Korhonen commented on TAP5-986:
-------------------------------------

This happens at least on Jetty and all versions, including 5.4 snapshots. The issue is related to servlet standard error pages and how (at least) Jetty handles error dispatches. You'll get the exception whenever a response.sendError is invoked, because the container's error dispatcher immediately starts processing the error request in the same thread. We probably don't see this in Tomcat because it likely issues a new thread for processing the error request. Anyway, Tapestry successfully cleans up the thread and ends processing the request, after which the original request finishes up, invoking EndOfRequestEventHub.fire() but the thread is already cleaned up. That also explains why everything still works even though you see the exception. A corrected, but naive implementation of EndOfRequestEventHub would check if the request still exists, for example (note the added "if (requestGlobals.getRequest() == null) return;" in fire() ):

        @ServiceId("GuardedEndOfRequestEventHub")
        public EndOfRequestEventHub buildEndOfRequestEventHub(final RequestGlobals requestGlobals) {
                return new EndOfRequestEventHub() {
                        private final List<EndOfRequestListener> listeners = CollectionFactory.newThreadSafeList();

                        public void addEndOfRequestListener(EndOfRequestListener listener) {
                                listeners.add(listener);
                        }

                        public void removeEndOfRequestListener(EndOfRequestListener listener) {
                                listeners.remove(listener);
                        }

                        public void fire() {
                                if (requestGlobals.getRequest() == null) return;
                                for (EndOfRequestListener l : listeners) {
                                        l.requestDidComplete();
                                }
                        }
                };
        }

It's easy to override the original EndOfRequestEventHub since it has no dependencies. That's just stopgap measure, I'll bring the topic of multiple container dispatches on the dev list as it may imply a larger issue with the expectations T5 makes about the isolation level of container threads.
                
> sendError in onActivate / Tapestry error dispatching
> ----------------------------------------------------
>
>                 Key: TAP5-986
>                 URL: https://issues.apache.org/jira/browse/TAP5-986
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: Christophe Cordenier
>         Attachments: TAP5-986.txt
>
>
> With this kind of configuration in web.xml :
> <filter-mapping>
> 	<filter-name>tapestryFilter</filter-name>
> 	<url-pattern>/*</url-pattern>
> 	<dispatcher>ERROR</dispatcher>
> 	<dispatcher>REQUEST</dispatcher>
> </filter-mapping>
> <error-page>
> 	<error-code>403</error-code>
> 	<location>/error/AccessDenied</location>
> </error-page>
> <error-page>
> 	<error-code>404</error-code>
> 	<location>/error/NotFound</location>
> </error-page>
> RestoreDirtySessionObjects is generating a NullPointerException with this line :
> Session session = request.getSession(false);
> It seems that the dispatching is done in one single thread, then the initial class to RestoreDirtySessionObjects is delay, and request object is lost.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira