[webbeans-issues] [JBoss JIRA] Created: (WBRI-257) <f:view> erases conversation id UIViewRoot attribute in JSF 2
1:24 p.m.
<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
1:01 a.m.
New subject: [webbeans-issues] [JBoss JIRA] Commented: (WBRI-257) <f:view> erases conversation id UIViewRoot attribute in JSF 2
[
https://jira.jboss.org/jira/browse/WBRI-257?page=com.atlassian.jira.plugi...
]
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
1:01 a.m.
New subject: [webbeans-issues] [JBoss JIRA] Resolved: (WBRI-257) <f:view> erases conversation id UIViewRoot attribute in JSF 2
[
https://jira.jboss.org/jira/browse/WBRI-257?page=com.atlassian.jira.plugi...
]
Dan Allen resolved WBRI-257.
----------------------------
Resolution: Done
Assignee: Dan Allen (was: Nicklas Karlsson)
<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: Dan Allen
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
5495
days inactive
5497
days old
2 comments
1 participants
participants (1)
-
Dan Allen (JIRA)