Affects Version/s: facesbridge-tck-2.0.0, facesbridge-tck-3.0.0, facesbridge-tck-4.0.0, facesbridge-tck-5.0.0
Component/s: FacesBridge TCK
The JSR 378 TCK was originally developed under JSR 329 for Portlet 2.0 + JSF 1.2. In order to facilitate XHR+ResourceRequest type requirements, the TCK depends on Apache Trinidad. In addition, the TCK utilized Trinidad's client-side state saving feature, as described by the following context-param in the TCK's WEB-INF/web.xml descriptor:
TestPage117 (encodeActionURLWithModeRenderTest) starts out with MultiRequestTest.jsp which is a simple form:
This will render an HTML form like the following:
Thanks to TestSuiteViewHandlerImpl.java, the value of the action attribute will be a JSF actionURL with the following URL parameters appended (prior to encoding of the URL):
When clicking on the commandButton, this should dispatch a full page HTTP POST to a portlet ActionURL. When the GenericTestSuitePortlet.processAction(ActionRequest actionRequest,ActionResponse actionResponse) method is invoked, the following should be true:
Because #3 is null, the bridge implementation will not know which view is to be restored in the RESTORE_VIEW phase of the JSF lifecycle, and as a result it will need to restore the MultiRequestTestResultRenderCheck.jsp view as specified in the TCK's WEB-INF/portlet.xml descriptor in order to determine the view for EDIT mode:
The problem is that Trinidad client-side state saving has a non-standard feature such that the viewId for MultiRequestTest.jsp is encoded in the client-side javax.faces.ViewState hidden field. This in turn causes MultiRequestTest.jsp to be restored rather than MultiRequestTestResultRenderCheck.jsp.
The TCK incorrectly depends on this, as is evidenced by the Tests.encodeActionURLWithModeRenderTest(TestRunnerBean) method having a condition for Bridge.PortletPhase.ACTION_PHASE. Such a condition could only be true if MultiRequestTest.jsp were restored (which is the Trinidad behavior). In order to compensate for this, the TCK has a navigation-rule in the WEB-INF/faces-config.xml descriptor that causes the MultiRequestTestResultRenderCheck.jsp to be rendered in the RENDER_RESPONSE phase of the JSF lifecycle:
The following tasks must be part of fixing this problem so that the TCK executes the test correctly:
1. Introduce a new ActionURLWithModePortlet class that extends GenericFacesTestSuitePortlet.java
2. Have ActionURLWithModePortlet.processAction(ActionRequest,ActionResponse) call actionResponse.setRenderParameter(String,Object) in order to save the portlet mode and the value of the "param1" parameter as render parameters that can be picked up in the RENDER_PHASE of the portlet lifecycle.
3. Modify the Tests.encodeActionURLWithModeRenderTest(TestRunnerBean) method so that it consults Bridge.PortletPhase.RENDER_PHASE instead of Bridge.PortletPhase.ACTION_PHASE
4. Remove the navigation-rule from faces-config.xml (but only when
FACES-2550 is complete – the navigation rule will still be required as long as Trinidad is part of the TCK)