Portlet Bridge Upgrade: All subsequent hits are a postback

[njanken]

We are upgrading from portlet bridge 1.0.0.CR2 to 2.1.0.Final and are having a flummoxing problem.  Has anyone run into this and has a solution?  The view seems to stay alive much longer than it should. 

Environment is:

JBoss Portlet Bridge 2.1.0.Final

RichFaces 3.3.1.GA

Facelets 1.1.14

JSF 1.2.3.2

WebLogic Portal 10.3.2

A symptom of the problem,

1) You go to a page with some required validations set. 

2) Trigger the validations so that you have some validation messages.

3) Refresh the page using the browser reset button

4) The validations messages are still there (this is bad)

Under the 1.0.0.CR2 portlet bridge, when you would refresh a page, or navigate away from a page, the view would not be restored.  This is causing catastrophic failures with a4j:includes and a4j:keepAlives.

I was mulling over what was a good basic test of what is happening here, and what is the basic difference between the old and new portlet bridges.  I have found that in the JSF restore view phase, on the new portlet bridge, it is incorrectly considering every hit after the first hit to be a postback, whereas it does not on the old bridge.  That is the basic problem from the JSF perspective.  If it was not considering this to be a postback, it would not try restore the view, and things would work properly.

On step 3 from above with portlet bridge 2.1.0 you see

/custorglockoutgcp/custOrgGCPLock.jspxIS NOT A POSTBACK

/setchallengequestions/setChallengeQuestions.jspxIS NOT A POSTBACK

/setlanguage/setLanguage.jspxIS A POSTBACK

/feedbackform/feedbackform.jspxIS A POSTBACK

On step 3 from above with 32 Bit VM and portlet bridge 1.0.0 you see

<Feb 18, 2011 5:37:57 AM GMT> <Notice> <Stdout> <BEA-000000> </custorglockoutgcp/custOrgGCPLock.jspxIS NOT A POSTBACK>

<Feb 18, 2011 5:37:57 AM GMT> <Notice> <Stdout> <BEA-000000> </setchallengequestions/setChallengeQuestions.jspxIS NOT A POSTBACK>

<Feb 18, 2011 5:37:57 AM GMT> <Notice> <Stdout> <BEA-000000> </setlanguage/setLanguage.jspxIS NOT A POSTBACK>

<Feb 18, 2011 5:37:58 AM GMT> <Notice> <Stdout> <BEA-000000> </feedbackform/feedbackform.jspxIS NOT A POSTBACK>

@Override

public void afterPhase(PhaseEvent event) {

  if(event.getPhaseId() == PhaseId.RESTORE_VIEW) {

   if(event.getFacesContext().getRenderKit().getResponseStateManager().isPostback(event.getFacesContext())) {

System.out.println(event.getFacesContext().getViewRoot().getViewId() + "IS A POSTBACK");

                                                          } else {

System.out.println(event.getFacesContext().getViewRoot().getViewId() +  "IS NOT A POSTBACK");

                                             }

                              }

               }

[njanken]

I'm looking at this further, and I'm noticing that AjaxPortletBridge.doFacesRequest has the following mechanism for setting up the BridgeRequestScope.

BridgeRequestScope windowState = requestStateManager.getRequestScope(

    stateId);

  if (null == windowState) {

   windowState = new BridgeRequestScope();

   requestStateManager.saveRequestScope(stateId, windowState);

  }

As far as I can see, RequestStateManager pulls out of the session, which means that all BridgeRequestScopes are totally session based.  Is that why all of the views are all now session scoped?  If so, is that correct?

[wesleyhales]

This issue was recently reported here: https://issues.jboss.org/browse/PBR-233

Since this is dictated by the spec, you can use this as a workaround (there is another mentioned in the issue comments):

http://fisheye.jboss.org/browse/PortletBridge/trunk/examples/richfaces/ajaxPortlet/src/main/java/Bean.java?r1=730&r2=853

[njanken]

Thanks Wesley.  The approach that we are looking at now, is subclassing GenericFacesPortlet and using our subclass in portet.xml.  We then feed ourselves a request parameter that indicates that we want to deliberatly reset the bridge request scope for that portlet. The code looks approximatly like the following.  This way we can achieve our goals without breaking the intentions of the spec.  What do you think?

package com.foo;

import java.io.IOException;

import javax.portlet.PortletException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.faces.GenericFacesPortlet;

import org.jboss.portletbridge.BridgeRequestScope;
import org.jboss.portletbridge.RequestScopeManager;
import org.jboss.portletbridge.StateId;

public class BarFacesPortlet extends GenericFacesPortlet {

  @Override
  protected void doDispatch(RenderRequest request, RenderResponse response)
  throws PortletException, IOException {
    if(request.getParameter("resetBridgeRequestScope") != null && request.getParameter("resetBridgeRequestScope").equals("true") ) {
      RequestScopeManager requestStateManager = RequestScopeManager.getInstance(request,RequestScopeManager.DEFAULT_MAX_MANAGED_SCOPES);
      StateId stateId = requestStateManager.getStateId(request, response);
      requestStateManager.saveRequestScope(stateId, new BridgeRequestScope());
   
    }

    super.doDispatch(request, response);
  }
}