Server Internal Error!

The session expiry popup doesn't show up because push is not enabled. Push is enabled lazily when you go to progress bar panel.

The exception shown (ViewExpiredException) occurs when you try interact with a view that has been disposed, usually because the session has expired. Now, we actually fixed this issue in the past, see http://jira.icefaces.org/browse/ICE-5271?focusedCommentId=28189&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_28189 .
Both ViewExpiredException and SessionExpiredException are queued and later on transformed into an error message by AjaxExceptionHandlerImpl exception handler. The problem is that the message is malformed:

<?xml version="1.0" encoding="utf-8"?>
<partial-response><error><error-name>class org.icefaces.push.servlet.SessionExpiredException</error-name><error-message><![CDATA[User session has expiredUser session has expired]]></error-message></error></partial-response>
<?xml version="1.0" encoding="utf-8"?>
<partial-response><error><error-name>class javax.faces.application.ViewExpiredException</error-name><error-message><![CDATA[viewId:/showcase.jsf - View /showcase.jsf could not be restored.viewId:/showcase.jsf - View /showcase.jsf could not be restored.]]></error-message></error></partial-response>

The JSF bridge error handler we register for displaying errors will receive only the ViewExpiredException as error message, the other one being discarded. The result is that only the popup containing ViewExpiredException is displayed.

So we can solve the popup not displaying issue by forcing comp. showcase into push mode on first page view if we want.

The issue with the incorrect error message eventually appearing can be resolved by either sending a patch to Mojarra JSF for AjaxExceptionHandlerImpl, or wire in an exception handler of our own that can send properly a list of error messages (at the app. level).

Now that Push can be activated as per the work in the linked case, it should be possible for the SessionExpired exception to be pushed out to the entire appllcation (providing that lazyPush is set to false).

It appears that, even without Push activated, when the session expires that the next interaction with the application results in a behaviour that's not quite right. In stepping through the JavaScript, I can see that the "User Session Expired" popup is displayed but then the URL location ends up getting set to:

http://localhost:8080/component-showcase/null

and Glassfish responds with:

HTTP Status 404 -
descriptionThe requested resource () is not available.

I've only tried this with Chrome and Glassfish 3 so I'm going to see what happens with Tomcat and Firefox.

Same behaviour in Firefox although it got rendered slow enough that you could see the Session Expired popup before the next page removed it.

I think it might be related the change in dispose-window to a form post as it looks like that might be occurring after the session expired response is received and processed.

The problem appears to be limited to compat. My current theory is that there is an additional listener that is being registered for the Session Expired exception and this second listener is causing the "null" request.

The issue was that when the framework was checking for context parameters that specified a redirect URI for session expiry, the actual String 'null' was being returned. The bridge was then interpreting that to be a valid URI and invoking the logic to redirect the page to /context/null. I added code to the bridge to check for the 'null' String and treat it as null for now but it's likely this isn't the best solution.