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

Section 6.1.3.1 of the FacesBridge Spec does not include requirements for TCK test 5.29

    Details

      Description

      Problem Background

      Regarding ExternalContext.getResponseContentType(), Section 6.1.3.1 of the JSR 329 Spec (titled "Methods that deviate from Faces 1.2 Javadoc") states:

      Return the MIME Content-Type for this response. If called during the RENDER_PHASE or RESOURCE_PHASE, returns the value from the corresponding render response.getContentType()[6.62, 6.129]. If called during the ACTION_PHASE or EVENT_PHASE it throws an IllegalStateException[6.63, 6.130].

      However, the tck-tests.md file contains the following test description, which describes a requirement for the bridge implementation (not the bridge's implementation of ExternalContext):

      [5.29] If RenderResponse.getContentType() returns null and there is no other indication of desired content type (not defined by this specification; i.e. an implementation specific extension) then the bridge must call RenderResponse.setContentType() passing the value returned from RenderRequest.getResponseContentType()

      There are two problems worth noting:
      1. The Apache MyFaces Portlet Bridge (the Reference Implementation for JSR 329) does not have any Java code that calls the RenderResponse.setContentType(String) method.
      2. The test for 5.29 does not check RenderResponse.getContentType() to see if it returns null (as described in the tck-tests.md file).

      If both of these problems exist, then why does Apache Pluto 2.0.x pass JSR 329 TestPage057 (bridgeSetsContentTypeTest)?

      One reason why it passes is because the test relies on SingleRequestTest.jsp, which contains the following line:

      SingleRequestTest.jsp
      <%@ page contentType="text/html;charset=UTF-8"%>
      

      This has the effect of generating java source code from the JSP that looks like the following:

      SingleRequestTest_jsp.java
      response.setContentType("text/html;charset=UTF-8");
      

      Another reason it passes is because Apache Pluto 2.0.x source contains the following implementation for RenderResponse.setContentType(String) which will remove ";charset=UTF-8" from the specified contentType:

      RenderResponseImpl.java (Apache License, Version 2.0)
          @Override
          public void setContentType(String contentType)
          {
              ArgumentUtility.validateNotNull("contentType", contentType);
              int index =contentType.indexOf(';');
              if (index != -1)
              {
                  contentType = contentType.substring(0, index);
              }
              contentType = contentType.trim();
              if (!isValidContentType(contentType))
              {
                  throw new IllegalArgumentException("Specified content type '" + contentType + "' is not supported.");
              }
              super.setContentType(contentType);
          }
      

      Proposal

      This issue serves as a proposal for:
      1. Adding a requirement to Section 6.1.3.1 so that ExternalContext.getResponseContentType() returns the value of RenderRequest.getContentType() if the return value of RenderResponse.getContentType() is null.
      2. Refactoring Test 5.29 to utilize a portlet-filter that decorates the RenderResponse, ensuring that RenderResponse.getContentType() returns null.
      3. Moving Test 5.29 from Section 5 to Section 6 in the tests.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                neil.griffin Neil Griffin
                Reporter:
                neil.griffin Neil Griffin
                Participants of an Issue:
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: