(Patch provided) Multiple Portlets Navigationproblem
----------------------------------------------------
Key: MYFACES-650
URL: http://issues.apache.org/jira/browse/MYFACES-650
Project: MyFaces
Type: Bug
Components: Implementation
Versions: Nightly
Environment: myfaces-api + myfaces-impl (rev. 292564) , pluto-1.0.1-rc4
(binary bundle), jdk1.5.0_03-b07
Reporter: Tanju Erinmez
First of all, congratulations to the TCK pass! Myfaces is a terrific product!
Especially the combination with portlets is a joy to work with!
However, I have come across a tiny little problem [1] which might be even
easier to fix [2,3] :-) I'm going to attach a patch as well as a demo war in
order to reproduce the issue if upload threshold permits.
It would be great if these patches could be included.
TIA,
Tanju
PS: This issue is not related to 549. I have analyzed that one as well and will
post a desc shortly.
[1] Scenario
------------------
The problem specifically arises when two (or more) portlets from the same war
deployable are positioned on the same page AND the state saving mode is set to
client. Well, the workaround would be to set it to server, however, the client
mode actually reveals the underlying issue.
Consider the following scenario:
6 jsp pages: view1.jsp... view6.jsp with one commandButton each
PortletA starts with view1 and iterates upon a buttonclick to view2, view3 and
back to view1 etc.
PortletB starts with view4 and moves on to view5, view6 and back to view4 etc
On startup, situation is: 1, 4
1. After action in A -> 2, 4
2. After action in B -> 2, 5
3. After action in A -> 2, 5 <- Wrong! should be 3, 5
4. After action in A -> 3, 5 <- Another action is needed to move to 3, 5
This behavior (inversed) also appears if the sequence is started with portlet B
instead of A.
[2] Possible explanation
------------------------------------
The actual problem is that a facesContext, which is kept in the PortletSession,
also drags a responseWriter along. However, this writer becomes stale as soon
as the processing of the respective view (underlying jsp) is concluded.
When this facesContext is retrieved by a subsequent RenderRequest the
UIComponentTag class will not create a new responseWriter, instead it will use
the one from the facesContext. (see UIComponentTag.java, setupResponseWriter())
Fastforward: The ViewTag instance (doAfterBody()) is not able to replace the
form state marker because the actual content has been written out to the
bodyContent of the last page and not the view-to-be. The consequence is that
the marker is written out as is.
Now as soon as action 3. is invoked, the resoreView phase is not able to
restore the tree. It just skips the other phases and goes straight for the
render phase which renders the current view again.
This problem does not occur in the non-portlet use-case because a new
facesContext (with a noninitialized responseWriter) is created upon every
request.
[3] Resolution
----------------------
A simple solution would be to just nullify all non-essential instance variables
of facesContext (specifically the _responseWriter variable) after the
facesContext is retrieved in facesRender() of MyFacesGenericPortlet.
A more symmetric solution would be to reset the responseWriter where it is
actually assigned namely in UIComponentTag but this does not seem to be
possible due to the API which does not permit a null value assignment. This
actually makes perfectly sense given its intention as throwaway object in a
well defined a lifecycle.
I have tested this fix on pluto, and it seems to work like a charm.
--
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
