You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Agam Dass (JIRA)" <de...@myfaces.apache.org> on 2009/12/08 04:55:18 UTC
[jira] Created: (MYFACES-2452) Myfaces doesn't provide support for
"Enable RestoreView 1.1 Compatibility" like sun ri implementation
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.
[jira] Commented: (MYFACES-2452) Myfaces doesn't provide support
for "Enable RestoreView 1.1 Compatibility" like sun ri implementation
Posted by "Agam Dass (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787394#action_12787394 ]
Agam Dass commented on MYFACES-2452:
------------------------------------
Introduce flag org.apache.myfaces.enableRestoreView11Compatibility which can be used to work in compatibility mode if set to true.
public boolean execute(FacesContext facesContext)
{
if (facesContext == null)
{
throw new FacesException("FacesContext is null");
}
// init the View
Application application = facesContext.getApplication();
ViewHandler viewHandler = application.getViewHandler();
viewHandler.initView(facesContext);
UIViewRoot viewRoot = facesContext.getViewRoot();
RestoreViewSupport restoreViewSupport = getRestoreViewSupport();
if (viewRoot != null)
{
if (log.isTraceEnabled())
log.trace("View already exists in the FacesContext");
viewRoot.setLocale(facesContext.getExternalContext().getRequestLocale());
restoreViewSupport.processComponentBinding(facesContext, viewRoot);
return false;
}
String viewId = restoreViewSupport.calculateViewId(facesContext);
// Determine if this request is a postback or initial request
if (restoreViewSupport.isPostback(facesContext))
{
if (log.isTraceEnabled())
log.trace("Request is a postback");
viewRoot = viewHandler.restoreView(facesContext, viewId);
if (viewRoot == null)
{
// check the new flag org.apache.myfaces.enableRestoreView11Compatibility to execute the below logic.
// See : https://issues.apache.org/jira/browse/MYFACES-2452
// To run the restore view in compatibility mode we need to make sure that
// in case of view is not found in the LRUMap; create a new view and flag that
// the response should be immediately rendered
if (log.isTraceEnabled())
log.trace("Postback: recreating a view for " + viewId);
viewRoot = viewHandler.createView(facesContext, viewId);
facesContext.renderResponse();
}
if (viewRoot == null)
{
throw new ViewExpiredException(
"No saved view state could be found for the view identifier: "
+ viewId, viewId);
}
restoreViewSupport.processComponentBinding(facesContext, viewRoot);
}
else
{
if (log.isTraceEnabled())
log.trace("Request is not a postback. New UIViewRoot will be created");
viewRoot = viewHandler.createView(facesContext, viewId);
facesContext.renderResponse();
}
facesContext.setViewRoot(viewRoot);
return false;
}
> 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.
[jira] Updated: (MYFACES-2452) Myfaces doesn't provide support for
"Enable RestoreView 1.1 Compatibility" like sun ri implementation
Posted by "Agam Dass (JIRA)" <de...@myfaces.apache.org>.
[ 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.