This turns out to be caused by the exception in the test case not having a message when it is generated. When the container fetches the error resource the framework executes another lifecycle because the resource is a Faces resource (page ends in .jspx in this case). This second lifecycle is attempting to restore state because the ViewState key is still in the request map.
This condition is noted in the JSF code and they attempt to have a workaround. The condition for a postback is
boolean isPostBack = (isPostback(facesContext) && !isErrorPage(facesContext));
The comment in isErrorPage is informative:
/**
- The Servlet specification states that if an error occurs
- in the application and there is a matching error-page declaration,
- the that original request the cause the error is forwarded
- to the error page.
*
- If the error occurred during a post-back and a matching
- error-page definition was found, then an attempt to restore
- the error view would be made as the javax.faces.ViewState
- marker would still be in the request parameters.
*
- Use this method to determine if the current request is
- an error page to avoid the above condition.
*
- @param context the FacesContext for the current request
- @return <code>true</code> if <code>WEBAPP_ERROR_PAGE_MARKER</code>
- is found in the request, otherwise return <code>false</code>
*/
private static boolean isErrorPage(FacesContext context)
{
return (context.getExternalContext().
getRequestMap().get(WEBAPP_ERROR_PAGE_MARKER) != null);
}
However if the exception generated is empty, the container puts nothing in the WEBAPP_ERROR_PAGE_MARKER request parameter for the request for the subsequent resource.
This would fail in stock JSF also. Only ICEfaces without state saving would work in this case, because with an existing viewRoot, the application wouldn't attempt to restore any viewRoot at all.
Bug
Major
This turns out to be caused by the exception in the test case not having a message when it is generated. When the container fetches the error resource the framework executes another lifecycle because the resource is a Faces resource (page ends in .jspx in this case). This second lifecycle is attempting to restore state because the ViewState key is still in the request map.
This condition is noted in the JSF code and they attempt to have a workaround. The condition for a postback is
boolean isPostBack = (isPostback(facesContext) && !isErrorPage(facesContext));
The comment in isErrorPage is informative:
/**
*
*
*
*/
private static boolean isErrorPage(FacesContext context) { return (context.getExternalContext(). getRequestMap().get(WEBAPP_ERROR_PAGE_MARKER) != null); }
However if the exception generated is empty, the container puts nothing in the WEBAPP_ERROR_PAGE_MARKER request parameter for the request for the subsequent resource.
This would fail in stock JSF also. Only ICEfaces without state saving would work in this case, because with an existing viewRoot, the application wouldn't attempt to restore any viewRoot at all.