You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Michael Freedman (JIRA)" <de...@myfaces.apache.org> on 2009/08/12 20:17:14 UTC
[jira] Resolved: (PORTLETBRIDGE-93) Exception thrown because
viewId's state can't be found by Faces during restore
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Freedman resolved PORTLETBRIDGE-93.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
1.0.0
As the bug states - fix is to only remove the viewId from the cache once a full render has completed and hence the view has been saved by Faces.
> Exception thrown because viewId's state can't be found by Faces during restore
> ------------------------------------------------------------------------------
>
> Key: PORTLETBRIDGE-93
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-93
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-beta, 2.0.0-alpha
> Reporter: Michael Freedman
> Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> When running in Pluto we get these intermittent Exceptions thrown during the render of a portlet that follows its action being submitted if there are (numerous) other portlets on the page.
> Turns out Pluto seems to timeout or something (a SocketException) is thrown. As this is the first render after the action -- the view hasn't been saved by Faces yet. Unfortunately, the code is written to handle (render) exceptions as something that should remove the request scope (so refresh won't just put you back in the same state). The consequence of this is the cached view is lost. As pluto handles this exception and recalls the render we get the ugly situation that when this second render fires we no longer have the view in the scope -- however we do have the scopeId and within it the VIEW_STATE_ID. Since we don't restore from cache, Faces does a full restore -- it uses the VIEW_STATE_ID attribute to look it up -- but fails because its never stored it. Instead it throws the above exception.
> Fix is to only remove the cached view from the bridge request scope after the view save has occurred. In addition, remove the code from the bridge that removes the entire scope if an exception is throw during a render.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.