[ http://issues.apache.org/jira/browse/MYFACES-650?page=comments#action_12330899 ]
Mike Kienenberger commented on MYFACES-650: ------------------------------------------- Have you looked at MYFACES-605? It deals with fixing responseWriter from a Servlet environment where it is also broken. Unfortunately, my understanding of portlets is almost non-existent, and I'd love to hear your comments on the issue with regards to the portlet environment. > (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 > Attachments: myfaces-impl-src.diff, navdemo.war > > 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
