[jira] Reopened: (WICKET-3011) strange context shutdown issue on jetty 7

["Peter Ertl (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl reopened WICKET-3011:
--------------------------------


Things seem to be a little trickier than expected. This is what Greg Wilkins answered:

>
> http://jira.codehaus.org/browse/JETTY-1266 
>
> Jetty has been this way for many many years without failing any compliance testing.  So I'm don't think I would describe 
> this as a bug. It's probably just an ambiguous section of the servlet spec.
>
> I will research in the next few days and see if I can find something definite in the spec that would imply we should change.
>
> Note that I'm not opposed to changing it, I just don't want to change it without due diligence, so that I don't get howls of 
> despair from developers who depend on the current ordering - ie so their filter can clean up elements in the sessions 
> (for example).

So obviously the 'different' order (compared to other web containers) is, at least based on compliance tests, not a 
bug but just some undefined behavior.

I really wonder why this shutdown issue in Wicket was not there earlier (maybe it was?!)

Due to the fact that jetty passes compliance tests we probably should still do something about this in Wicket.


> 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 FROM THE THREAD LOCAL
> ///////////////
> 			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.