Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
1.1.2-SNAPSHOT
-
None
-
None
-
myfaces-api + myfaces-impl (rev. 292564) , pluto-1.0.1-rc4 (binary bundle), jdk1.5.0_03-b07
Description
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.