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.

        Activity

        Hide
        kyle.stiemann Kyle Stiemann added a comment -

        Neil Griffin, this issue is not advocating the removal of the entirety of the JSP_ELTest correct? It only advocates removing the parts of the test that are no longer valid in Portlet 3.0 right?

        Show
        kyle.stiemann Kyle Stiemann added a comment - Neil Griffin , this issue is not advocating the removal of the entirety of the JSP_ELTest correct? It only advocates removing the parts of the test that are no longer valid in Portlet 3.0 right?
        Hide
        neil.griffin Neil Griffin added a comment -

        @Kyle Stiemann: Correct. The original title of this ticket may have implied that the entirety of JSP_ELTest should be removed, but it was since updated to be "Remove some of the tests ..."

        Show
        neil.griffin Neil Griffin added a comment - @ Kyle Stiemann : Correct. The original title of this ticket may have implied that the entirety of JSP_ELTest should be removed, but it was since updated to be "Remove some of the tests ..."
        Hide
        kyle.stiemann Kyle Stiemann added a comment -

        +1

        Show
        kyle.stiemann Kyle Stiemann added a comment - +1
        Hide
        javajuneau Josh Juneau added a comment -

        +1, I think test cleanup is a very good thing to do

        Show
        javajuneau Josh Juneau added a comment - +1, I think test cleanup is a very good thing to do
        Hide
        vernon.singleton Vernon Singleton added a comment -

        +1

        Show
        vernon.singleton Vernon Singleton added a comment - +1
        Hide
        kfyten Ken Fyten added a comment -

        +1

        Show
        kfyten Ken Fyten added a comment - +1
        Hide
        juan.gonzalez Juan Gonzalez added a comment -

        +1

        Show
        juan.gonzalez Juan Gonzalez added a comment - +1

          People

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

            Dates

            • Created:
              Updated:

              Development

                Subcomponents