You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Peter Ertl (JIRA)" <ji...@apache.org> on 2010/09/21 21:46:35 UTC
[jira] Issue Comment Edited: (WICKET-3011) strange context shutdown
issue on jetty 7
[ https://issues.apache.org/jira/browse/WICKET-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913202#action_12913202 ]
Peter Ertl edited comment on WICKET-3011 at 9/21/10 3:44 PM:
-------------------------------------------------------------
The shutdown order is "fixed" in the latest version of jetty, according to Greg Wilkins, the father of jetty.
see http://jira.codehaus.org/browse/JETTY-1266
> OK, I'm kind of convinced that it's a good idea.
> But I have to work out how to do it nicely in the code. In Jetty we have nested handlers, with Context->Session->Security->Servlet,
> so that is why filters (as part of the Servlet Handler) are destroyed before sessions - it's the natural nesting of the stop method.
>
> Turns out the code change is trivial... and better yet, not jetty test cases failed as a result.
> So committed to jetty-7 trunk r2286
>
So there's no reason to mess around with this but recommend people to upgrade to to jetty 7.1.7 (or 7.2) which should be out soon.
was (Author: pete):
The shutdown order is "fixed" in the latest version of jetty, according to Greg Wilkins, the father of jetty.
see http://jira.codehaus.org/browse/JETTY-1266:
> OK, I'm kind of convinced that it's a good idea.
> But I have to work out how to do it nicely in the code. In Jetty we have nested handlers, with Context->Session->Security->Servlet,
> so that is why filters (as part of the Servlet Handler) are destroyed before sessions - it's the natural nesting of the stop method.
>
> Turns out the code change is trivial... and better yet, not jetty test cases failed as a result.
> So committed to jetty-7 trunk r2286
>
So there's no reason to mess around with this but recommend people to upgrade to to jetty 7.1.7 (or 7.2) which should be out soon.
> strange context shutdown issue on jetty 7
> -----------------------------------------
>
> Key: WICKET-3011
> URL: https://issues.apache.org/jira/browse/WICKET-3011
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Reporter: Peter Ertl
> Assignee: Peter Ertl
>
> when using jetty 7, creating at least one http session and then shutting down the web app context of the wicket web application the following happens:
> - (1) jetty destroys the wicket filter by calling javax.servlet.Filter#destroy()
> - (2) the thread local mapping application key ---> application will be purged
> - (3) jetty calls org.apache.wicket.session.SessionBindingListener.valueUnbound for the expiring session:
> --code--
> public void valueUnbound(final HttpSessionBindingEvent evt)
> {
> if (log.isDebugEnabled())
> {
> log.debug("Session unbound: " + sessionId);
> }
> ///////////////
> ////////////// THE APPLICATION WILL BE NULL SINCE THE
> ////////////// WICKET FILTER ALREADY REMOVED IT
> ///////////////
> Application application = Application.get(applicationKey);
>
> if (application == null)
> {
> ///////////////
> /////////////// YOU WILL SEE THE MESSAGE BELOW
> ///////////////
> log.error("Wicket application with name '" + applicationKey + "' not found.");
> return;
> }
> ///////////////
> /////////////// NO LISTENERS WILL BE INVOKED
> ///////////////
> ISessionStore sessionStore = application.getSessionStore();
> if (sessionStore != null)
> {
> for (UnboundListener listener : sessionStore.getUnboundListener())
> {
> listener.sessionUnbound(sessionId);
> }
> }
> }
> --code--
> Can somebody confirm the order jetty executes the handlers is right / wrong?
> In case it's wrong we should file a ticket at jetty.
> In case it's right we should fix that issue in wicket.
> Not fixing this incorrect behavior will mean the session unbound listeners will not be called reliably.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.