incubator-adffaces-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary VanMatre (JIRA)" <adffaces-iss...@incubator.apache.org>
Subject [jira] Commented: (ADFFACES-291) The StateManagerImpl fails to verify the viewId of the restored view matches the request viewId.
Date Thu, 16 Nov 2006 01:41:38 GMT
    [ http://issues.apache.org/jira/browse/ADFFACES-291?page=comments#action_12450254 ] 
            
Gary VanMatre commented on ADFFACES-291:
----------------------------------------

There is an example of this in the Shale sandbox.  The welcome (index.jsf) page has a link
that raises an exception in a action callback.

http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/

When you use the Shale view controller, it catches exceptions so that the view controller
callbacks are still invoked.  At the end of invoke application phase, a phase listener will
dispatch to a path/page if specified.  In this example, it's "/error.jsf". 

In this testbed, I wanted to show the raised exceptions on a JSF page versus a plain JSP or
static html page.  That's when I ran into the problem.   I found that the target (dispatch)
view was not being created but the previous view was restored.

Outside of this usecase, I think we could recreate it in an action call back that completed
the response (responseComplete) and used the external context to dispatch to another view.
  There is obviously a better way to programmatically handle navigation but this is an option.
 I expect that's why the myfaces runtime state manager has this check too.



> The StateManagerImpl fails to verify the viewId of the restored view matches the request
viewId.
> ------------------------------------------------------------------------------------------------
>
>                 Key: ADFFACES-291
>                 URL: http://issues.apache.org/jira/browse/ADFFACES-291
>             Project: MyFaces ADF-Faces
>          Issue Type: Bug
>            Reporter: Gary VanMatre
>         Attachments: StateManagerImpl.patch
>
>
> The Trinidad state manager is only interested in restoring state when client side state
is activated.  There is a scenario in the invoke application phase that a baking callback
or a phase listener might choose to dispatch to another faces view.  Since this delegation
is a forward, the client's state of the previous view still exists in the request.  The view
state is restored on the previous view's state.  
> The myfaces  JspStateManagerImpl performs this check in the restoreView method.
> Snippet:
> if (restoredViewId == null || !(restoredViewId.equals(viewId))) {

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message