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
- No evidence of session being invalidated. Stock JSF creates
new sessions to handle processing of various things during subsequent
steps of the lifecyle.
- NullPointerException popup
- ViewExpiredException popup
- Server Internal Error popup (NullPointerException may be behind
it but it's smaller)
- 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:
- The NullPointerExceptions are because of some Window scope
processing. It expects to find stuff in the session map that
isn't there.
- 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.
- 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.