myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tanju Erinmez (JIRA)" <>
Subject [jira] Updated: (MYFACES-650) (Patch provided) Multiple Portlets Navigationproblem
Date Fri, 30 Sep 2005 02:37:48 GMT
     [ ]

Tanju Erinmez updated MYFACES-650:

    Attachment: navdemo.war

demonstrates navigation problem with 2 portlets

> (Patch provided) Multiple Portlets Navigationproblem
> ----------------------------------------------------
>          Key: MYFACES-650
>          URL:
>      Project: MyFaces
>         Type: Bug
>   Components: Implementation
>     Versions: Nightly
>  Environment: myfaces-api + myfaces-impl (rev. 292564) , pluto-1.0.1-rc4 (binary bundle),
>     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, 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:
For more information on JIRA, see:

View raw message