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.