[webbeans-issues] [JBoss JIRA] Commented: (WBRI-257) <f:view> erases conversation id UIViewRoot attribute in JSF 2

Dan Allen (JIRA) jira-events at lists.jboss.org
Fri May 8 02:01:46 EDT 2009


    [ https://jira.jboss.org/jira/browse/WBRI-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12466436#action_12466436 ] 

Dan Allen commented on WBRI-257:
--------------------------------

As it turns out, JSF 2.0 wasn't saving the view root attribute because it now uses a flag "initialState" which it sets when it sees <f:view> in the template. Anything assigned to the attributes map on UIViewRoot before that call is basically ignored (think of it as a tare). This is part of the new partial state saving being implemented in 2.0. Oddly enough, if <f:view> isn't used, it never sets this flag and then it doesn't ignore the attribute we set.

There is another reason why we shouldn't store the conversation id during the before Render Response phase of a phase listener. With the new PreRenderViewEvent, it is now possible to alter the viewId (and thus UIViewRoot) zero or more times during the Render Response phase. So there is a good chance the token will get lost in that activity.

I have decided that using a UIViewRoot attribute is a fragile approach to propagating the conversation id across requests. A far more stable and portable approach is to add it as a request parameter to the query string of any URL that JSF uses. That opens the possibility for any mechanism (filter, phase listener, etc) to read this value on the next request and restore the conversation. It is no longer tied to JSF.

So how is this done. Fortunately, any URL that JSF builds is created using the getActionURL() method on ViewHandler. So it's simply a matter of providing a forwarding ViewHandler that overrides this one method and weaves in the conversation id. This covers all cases: form actions, link hrefs, Ajax calls, and redirect URLs.

> <f:view> erases conversation id UIViewRoot attribute in JSF 2
> -------------------------------------------------------------
>
>                 Key: WBRI-257
>                 URL: https://jira.jboss.org/jira/browse/WBRI-257
>             Project: Web Beans
>          Issue Type: Bug
>          Components: Contexts
>    Affects Versions: 1.0.0.PREVIEW1
>            Reporter: Dan Allen
>            Assignee: Nicklas Karlsson
>             Fix For: 1.0.0.PREVIEW2
>
>
> JSF 2 now builds the view in the Render Response phase. If JSF encounters the <f:view> tag while building the view, it resets the UIViewRoot, wiping out any attributes that might have been set in a phase listener before the Render Response phase. Thus, the conversation id becomes a vicitim of this sweep:
> FacesContext.getCurrentInstance().getViewRoot().getAttributes().put(CONVERSATION_PROPAGATION_KEY, cid);
> This problem is not present in JSF 1 since the view is already constructed by the time this call is made by the WebBeansPhaseListener before the Render Response phase.
> The solution is to approach conversation propagation differently for JSF 2. Instead of using a phase listener, a SystemEventListener should be used that monitors the PreRenderViewEvent. SystemEventListeners can be registered programmatically, which should be done sometime after JSF 2 starts (the version of JSF can be detected in WebBeans)

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

        



More information about the weld-issues mailing list