Uploaded image for project: 'PUBLIC - Liferay Faces'
  1. PUBLIC - Liferay Faces
  2. FACES-2981

Remove some of the tests from FacesBridge TCK TestPage204 (JSP_ELTest) since Portlet 3.0 has made them untestable and obsolete

    Details

      Description

      Problem Description / TCK Test Failure

      When running the JSR 378 FacesBridge TCK in Pluto 3.0, TestPage204 (JSP_ELTest) contains several failures.

      The test verifies that the FacesBridge ELResolver delegates to the portlet container when resolving JSP (not Facelet, but JSP) EL expressions such as the following:

      chapter6_5.jsp
      <%-- portletConfig --%>
      <c:set var="tck_portletConfig" value="${portletConfig}" scope="page"/>
      
      <%-- renderRequest --%>
      <c:set var="tck_renderRequest" value="${renderRequest}" scope="page"/>
      
      <%-- renderResponse --%>
      <c:set var="tck_renderResponse" value="${renderResponse}" scope="page"/>
      
      <%-- portletSession --%>
      <c:set var="tck_portletSession" value="${portletSession}" scope="page"/>
      
      <%-- portletPreferences --%>
      <c:set var="tck_portletPreferences" value="${portletPreferences}" scope="page"/>
      

      As part of the test, the chapter6_5.jsp view purposefully omits the <portlet:defineObjects/> tag in order to ensure that the EL expressions listed above store null values in their corresponding a JSP pageContext attributes.

      The reason why this fails with Pluto 3.0 is because of the following requirement in the Portlet 3.0 Spec:

      20.3 Portlet Predefined Beans (p.122)
      The portlet container must produce named beans that can be used in a JSP or a JavaServerTM Faces Facelet."

      Pluto 3.0 implements this by adding a @Named annotation for CDI producers such as the one for the PortletConfig object. This has the result of always resolving expressions such as ${portletConfig} to a non-null value.

      Background

      JSR 168 (released in 2003) didn't have the ability to take advantage of the concept of an ELResolver since it wasn't introduced until Java EE 5 (JSP 2.1) in 2005.

      Because of this, there was no standard way for a JSR 168 portlet container to introduce variables into a JSP. The <portlet:defineObjects/> JSP tag is probably a workaround for that. Unfortunately it burdens the developer with adding the tag by hand to each JSP that requires portlet objects to be resolved via EL.

      Conclusion

      Portlet 3.0 tries to simplify JSP development by automatically making the aforementioned objects resolve via EL as named beans. Since expressions like ${portletConfig} will always resolve to a non-null value, JSP_ELTest is no longer able to fully pass. Since they are untestable and obsolete, tests for the aforementioned EL expressions are to be removed.

      In addition, the following language should also be deleted from the Spec:

      In addition, the bridge must not resolve these variables outside of a Faces expression[6.100]. Note: The mechanism Faces provides for registering a EL resolver causes the EL resolver to be inserted into the resolution chain for both Faces expressions and JSP expressions. For the above objects, the bridge's EL resolver must delegate resolution to the JSP resolver within JSP expressions while resolving them within Faces expressions.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: