[
https://issues.apache.org/jira/browse/MYFACES-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Agam Dass updated MYFACES-2452:
-------------------------------
Status: Patch Available (was: Open)
> Myfaces doesn't provide support for "Enable RestoreView 1.1 Compatibility"
> like sun ri implementation
> ------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-2452
> URL: https://issues.apache.org/jira/browse/MYFACES-2452
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 1.2.8
> Environment: Window, Linux, AIX, JBoss and WAS app server, AJAX4JSF,
> Jsf1.2, Facelets 1.1.14
> Reporter: Agam Dass
>
> JSF 1.2
> Facelets 1.1.14
> AJAX4JSF [richfaces-ui-3.3.2.SR1]
> State Saving : Server
> Myfaces implementation doesn't provide support for the compatibility
> RestoreView according to JSF1.1 where if viewroot is null, it will be
> created again instead of throw ViewExpiredException. Sun JSF RI provides a
> compatibility mode using parameter
> com.sun.faces.enableRestoreView11Compatibility in the web.xml and then if
> configured it will be consulted while taking decision to create the view
> again or throw the ViewExpired exception.
> Due to this after moving to JSF 1.2 it keep on throwing VewExpiredException
> if couldn't be found in the session map, when state saving method is server.
> Please refer to the code in class
> com.sun.faces.lifecycle.RestoreViewPhase#execute method
> -------------------------------------------------------------------------------------------------------
> public void execute(FacesContext facesContext) throws FacesException {
> :
> boolean isPostBack = (facesContext.isPostback() &&
> !isErrorPage(facesContext));
> 196 if (isPostBack) {
> 197 facesContext.setProcessingEvents(false);
> 198 // try to restore the view
> 199 viewRoot = viewHandler.restoreView(facesContext, viewId);
> 200 if (viewRoot == null) {
> 201 if (is11CompatEnabled(facesContext)) {
> 202 // 1.1 -> create a new view and flag that the
> response should
> 203 // be immediately rendered
> 204 if (LOGGER.isLoggable(Level.FINE)) {
> 205 LOGGER.fine("Postback: recreating a view for
> " + viewId);
> 206 }
> 207 viewRoot = viewHandler.createView(facesContext,
> viewId);
> 208 facesContext.renderResponse();
> 209
> 210 } else {
> 211 Object[] params = {viewId};
> 212 throw new ViewExpiredException(
> 213 MessageUtils.getExceptionMessageString(
> 214
> MessageUtils.RESTORE_VIEW_ERROR_MESSAGE_ID,
> 215 params),
> 216 viewId);
> 217 }
> 218 }
> 219
> 220 facesContext.setViewRoot(viewRoot);
> 221 facesContext.setProcessingEvents(true);
> 222 if (LOGGER.isLoggable(Level.FINE)) {
> 223 LOGGER.fine("Postback: restored view for " + viewId);
> 224 }
> 225 }
> -------------------------------------------------------------------------------------------------------------------------------------
> Similar support should be provided by Mayfaces also. With sate saving as
> server, the state saving/restoring is not very reliable and throw VEE many a
> times. RichFaces also uses the parameter
> com.sun.faces.enableRestoreView11Compatibility to run its test suite.
> This is really a blocking issue until the problem of state saving at server
> is not fully solved and made reliable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
