myfaces-dev mailing list archives

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

         Key: MYFACES-650
     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

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.


PS: This issue is not related to 549. I have analyzed that one as well and will post a desc

[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
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

[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