7.1.2 Version Considerations
The following Faces implementation versions implement its dependent write behind behavior exclusively in a
ServletResponseWrapper without independently defining a non-Servlet dependent interface:
Mojarra 1.2_03
All released version of MyFaces 1.2 (current version is 1.2.9)
I.e.
the Faces view tag handler(s) test to see if the response supports its
write behind behavior involves checking whether the response object is an
instance of the particular
ServletResponseWrapper it has implemented.
Because, the bridge's write behind wrapper mechanism requires the behavior be implemented in an object that both extends
PortletResponseWrapper and implements the
BridgeWriteBehindResponse
interface, this mechanism is incompatible with the above versions.
If the target runtime environment will contain any of these
versions, one must use this servlet filter mechanism to support the
write behind behavior.
7.1.3 Performance Considerations
Through the use of the request attribute to signal the filter to
introduce its support, the mechanism is designed to have
negligible impact when
invoked from non-portlet requests. However, some overhead
exists
because the Servlet container has to determine whether this filter
should be called (i.e. if its an include) and if invoked whether the
filter needs to act (based on existence/setting of the
javax.portlet.faces.RenderContentAfterView
attribute.
In addition, because this facility isn't provided by default;
setting
up
the filter requires extra configuration. Because many JSF/JSP
pages aren't coded in a manner that exhibits this ordering problem,
portlet developers should keep the above in mind when deciding whether
enabling the filter in their application is justified.
7.2 Support via Portlet 2.0 ResponseWrapper
The bridge's
PortletResponseWrapper mechanism follows a pattern similar to Faces
ServletResponseWrapper mechanism. The bridge has the follow responsibility:
- In the bridge's ViewHandler, prior to dispatching to the JSP, replace the existing ExternalContext response with one that subclasses the appropriate phase's PortletResponseWrapper class and implements the bridge's javax.portlet.faces.BridgeWriteBehindResponse interface.
- Dispatch to the JSP.
- Restore the prior ExternalContext response
- Call the wrapper's hasWriteBehindMarkup() method and if it returns true and something hasn't already set the javax.portlet.faces.AfterViewContent
request attribute then hold onto the wrappers content for later output.
Otherwise, write its buffered content to the response.
- Render the Faces view.
- Output the (cached) after view content.
For this mechanism to work, the
PortletResponseWrapper
must additionally support the particular Faces dependent API used by
the (view) tag handler to flush the prior view content. The particular
wrapper used by the bridge is configured by the portlet in
faces-config.xml.
In the absence of such configuration, the bridge may use its own
response wrapper that is designed to work automatically in the Faces
environments it targets. For example, where
Faces write behind implementations exist that have their tag handlers
rely on Java reflection to determine support, the implementation of the
default response wrapper
should support any such additional APIs as needed by these
implementations to allow these classes to be used directly in the above
mechanism and achieve write behind behavior.
7.2.1 Configuring the Bridge to use a PortletResponseWrapper/WriteBehindResponse implementation
One
configures the particular implementation of the
RenderResponseWrapper
and/or
ResourceResponseWrapper the bridge uses as the response object
it dispatches to
in the bridge's application-extension
section of the
face-config.xml.
The syntax for this is described
in portlet2.0-bridge-faces1.2-faces-config-extensions.xsd.
<application>
<application-extension>
<bridge:write-behind-response-wrappers>
<bridge:render-response-wrapper-class>
org.mypackage.MyWriteBehindRenderResponseWrapper
</bridge:render-response-wrapper-class>
<bridge:resource-response-wrapper-class>
org.mypackage.MyWriteBehindResourceResponseWrapper
</bridge:resource-response-wrapper-class>
</bridge:write-behind-response-wrappers>
</application-extension>
</application>
7.2.2 Version Considerations
Mojarra version 1.2_03 tag handlers detect write behind support by using
instanceof a particular
ServletResponseWrapper class. This class is incompatible with this
PortletResponseWrapper mechanism, hence only the
ServletFilter mechanism can be used to add write behind support.
Mojarra version 1.2_04 through 1.2_07 tag handlers detect write behind support by using
instanceof a particular interface (
InterleavingResponse)
the response object might additionally implement. In such an
environment, developers need to implement and configure appropriate
PortletResponseWrapper classes that additionally implement both the
BridgeWriteBehindResponse interface and the
InterleavingResponse interface.
Mojarra
version 1.2.08 through current (1.2_13) tag handlers detect write
behind behavior by using Java reflection to detect if the response
class implements the needed method. The supported methods
correspond to those methods defined in the
InterleavingResponse interface. The bridge should implement and use default
PortletResponseWrapper classes that not only implements the
BridgeWriteBehindResponse interface but also supports the methods defined in the
InterleavingResponse
interface. In such circumstances, because reflection is being
used, the bridge can continue to be Faces implementation independent
yet still automatically support write behind behavior when run in
one of these versions. If a particular bridge doesn't naturally support
these methods, a developer can enable write behind support by
configuring the application with the same write behind
PorttletResponseWrapper(s) that work for versions 1.2_04-1.2_07.
All (existing) MyFaces versions (1.2.2-1.2.9) tag handlers detect write behind support by using
instanceof a particular
ServletResponseWrapper class. This class is incompatible with this
PortletResponseWrapper mechanism, hence only the
ServletFilter mechanism can be used to add write behind support.