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

Delete the requirements in chapter 7 of the Spec titled "WriteBehindResponse" and associated API & TCK Tests



      After View Content

      Chapter 7 of the JSR 329 Spec titled "WriteBehindResponse" was written to specify requirements for the bridge to support "after view content," meaning plain HTML markup in a JavaServer Pages (JSP) view that is found after the closing </f:view> tag. For example:

      <?xml version="1.0" encoding="UTF-8"?>
      	xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:h="http://java.sun.com/jsf/html"
      	xmlns:f="http://java.sun.com/jsf/core" xmlns:portlet="http://java.sun.com/portlet" version="2.1">
              <h:outputText value="hello world inside f:view" />
          <span>hello world after f:view</span>

      Chapter 7 of the JSR 329 Spec correctly states:

      To preserve the natural order (of literal strings/static html or jsp/java rendered markup) in a JSP, Faces 1.2 utilizes an implementation dependent write behind mechanism ...

      Chapter 7 also correctly states:

      the JSF specification prescribes this (write behind) behavior without formalizing the mechanism

      However, Chapter 7 then incorrectly states that:

      the bridge must (formalize the mechanism).

      Problem Background

      In order to understand the root of the problem, refer to the com.sun.faces.application.ViewHandlerImpl#executePageToBuildView(FacesContext,UIViewRoot) method which decorates the response in the javax.faces.context.ExternalContext with com.sun.faces.application.ViewHandlerResponseWrapper. Since ViewHandlerResponseWrapper extends javax.servlet.http.HttpServletResponseWrapper, the Mojarra implementation introduces a dependency on the Servlet API that can cause the bridge to encounter a ClassCastException from javax.portlet.PortletResponse to javax.servlet.http.HttpServletResponse. The Apache MyFaces implementation does the same type of thing, and also decorates the request in the javax.faces.context.ExternalContext causing a ClassCastException from javax.portlet.PortletRequest to javax.servlet.http.HttpServletRequest.

      Liferay Faces Bridge Solution

      Although the Liferay Faces Bridge implementation of JSR 329 passes 100% of the TCK tests, it is able to rely entirely on the Mojarra/MyFaces implementations to execute the "write behind" feature, thereby supporting "after view content" in a JSF portlet environment. It does this by decorating the PortletRequest with a wrapper that also implements HttpServletRequest. Similarly, it decorates the PortletResponse with a wrapper that also implements HttpServletResponse. To prove that this works, the bridge's BridgeWriteBehindResponseRenderImpl.java and BridgeWriteBehindResponseResourceImpl.java classes implement javax.portlet.faces.BridgeWriteBehindResponse but all the methods throw an UnsupportedOperationException. Since those methods never get called, the UnsupportedOperationException does not cause TCK failures.


      This issue serves as a proposal for the following:

      Although these are technically "breaking changes" to the API, the BridgeWriteBehindResponse interface and the aforementioned constants were only intended to be referenced by bridge implementations internally, and never intended to be referenced by JSF portlet developers in their JSF portlet applications.




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


              • Created:


                Version Package