In building and testing an application that invalidates the session through various means, there were some relevant observations:

Stock JSF

When invalidating the session programmatically with stock JSF (no ICEfaces or Ajax), processing continues and new sessions are created as required. For example, if we dump a portion of the stack from an HttpSessionListener.sessionCreated method, we can see that JSF will create new sessions for things that it needs to do.

[#|2010-08-16T16:54:44.312-0700|SEVERE|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=26;_ThreadName=Thread-1;|java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1230)
at org.icefaces.test.invalidate.SessionUtil.sessionCreated(SessionUtil.java:36)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:411)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:391)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:889)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:326)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2804)
at org.apache.catalina.connector.Request.getSession(Request.java:2528)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:919)
at com.sun.faces.context.SessionMap.getSession(SessionMap.java:225)
at com.sun.faces.context.SessionMap.put(SessionMap.java:122)
at com.sun.faces.context.SessionMap.put(SessionMap.java:57)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.getResponseEncoding(FaceletViewHandlingStrategy.java:951)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:860)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:364)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:127)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:117)

Even invalidating the session in the post RenderReponse phase (via a PhaseListener) will cause JSF to create a new session to write the state into. Since the new session is not aligned with the clients session id, the next interaction with the page will throw a ViewExpiredException, which can be configured in the web.xml to redirect to a new page.

I should note that with stock JSF, you can also use the strategy of redirecting to a JSP page and calling <%session.invalidate%> from there. After that, if you use the back button and then try and interact with the original page, the ViewExpiredException is thrown and can be handled via the error-page configured in the web.xml. I've added this scenario to the test case:

<error-page>
<exception-type>javax.faces.application.ViewExpiredException</exception-type>
<location>/faces/viewExpired.xhtml</location>
</error-page>

I've checked in my invalidation test case under icefaces/samples/test/invalidate. I'm also attaching an HTML page that summarizes the current state of affairs and what might need to be done to fix the various issues.

I've made more improvements to the test case as well as checked in some change to help with some of the inconsistencies. There is now a SessionExpiredListener that listens for sessionDestroyed() events and, if they were caused programmatically via session.invalidate() will push a SessionExpiredException onto the queue which is in turn delivered to the client in our standard popup. This is more accurate than the ViewExpiredException and occurs before the WindowScope has a chance to complain which makes it fail faster (a good thing).

When a session times out, the next interaction with the application will throw the ViewExpiredException. This is because there is no FacesContext available when this occurs (it's doesn't happen during a request) and the ViewExpiredException occurs when the view is being restored and still under JSF control.

I've also changed how the compat versions of the "Server Internal Error" popups are being restrained. It's now wired to a NOOP rather than disabling them altogether which would have interfered with the status component.