Invalidation Technique Stock JSF ICEfaces ICEfaces Compat

without icefaces.jar with icefaces.jar without icefaces-compat.jar with icefaces-compat.jar
actionListener 1 1 2 4 4
actionListener via Ajax 1 1 n/a
 n/a
 n/a
filter n/a works 3 5 5
filter n/a works n/a
 n/a
 n/a
logout.jsp works works 3 5 5
passive timeout





Overview

The test has 3 separate pages, stock/start.xhtml, ice/start.xhtml, and compat/start.xhtml that can be loaded depending on the other libraries that are included (icefaces.jar, icefaces-compat.jar).  On each page are some different ways of invalidating the session.

Invalidation Techniques

actionListener

A commandButton is bound to an actionListener method on the backing bean.  The method simply invalidates the session using the standard JSF API:
FacesContext fc = FacesContext.getCurrentInstance();
ExternalContext ec = fc.getExternalContext();
ec.invalidateSession();

actionListener via Ajax

Same as the previous item but uses the f:ajax tag to send the request.

filter

A commandButton is bound to an actionListener method on the backing bean.  Rather than invalidate the session directly, a flag is set in the request attributes.  The test included a SessionInvalidationFilter which, if the flag is present, would invalidate the session just as the response was outbound.  This allows the session to be invalidated after the JSF lifecycle has completed, rather than in the middle of it.

filter via Ajax

Same as the previous item but uses the f:ajax tag to send the request.

logout.jsp

A command link is used to goto logout.jsp page which invalidates the session like so:
<% session.invalidate(); %>
The back button can then be used to return to the original page where the next interaction with the page should not succeed.

Results

  1. No evidence of session being invalidated.  Stock JSF creates new sessions to handle processing of various things during subsequent steps of the lifecyle.
  2. NullPointerException popup
  3. ViewExpiredException popup
  4. Server Internal Error popup (NullPointerException may be behind it but it's smaller)
  5. Both Server Internal Error and ViewExpiredException popups

Conclusions

Looks like even stock JSF has some issues when trying to invalidate the session programmatically because throughout the lifecycle it creates new sessions whenever it requires it (e.g. saving state). This can be worked around with the filter mechansim.

As for the various popups, I think it boils down to a couple of issues:
  1. The NullPointerExceptions are because of some Window scope processing.  It expects to find stuff in the session map that isn't there.
  2. With non-compat ICEfaces, when we do see an exception, we send it back to the client.  If an exception is not allowed to bubble up to the container, it can't use the error-page mechanism to redirect.
  3. With compat ICEfaces, we have a similar issue. We may be getting two popups because both client side libraries are handling the error?  Just a guess at the moment.