[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman updated PORTLETBRIDGE-77:
------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
1.0.0
Status: Resolved (was: Patch Available)
The proposed version check is needed because there is/was a need to disable a
bridge workaround in systems that don't need as the workaround impacted running
on certain portlet containers (Liferay). I have added the version check --
which mostly works as there is no standard for getting the version and the
various potential distribution (even within a project/type) vary across
releases. But in addition I think I have fixed the underlying problem that
this version/disable check was being made for. Basically, Liferay in
dispatching to its local portlet container relied on the servlet dispatcher in
such a way as it caused the javax.serlvet.include attributes to get written --
specifically the pathInfo one. The bridge's "workaround" involves setting the
servletPath one -- but since Faces starts with the .include.pathInfo first --
Liferay's setting gets processed by Faces and no viewId is recovered. I have
now modified the bridge to clear these attrbiutes during ExternalContext
construction and restoring them on release. This should avoid the issue with
Liferay and let the stuff run whether or not the bridge's hack of setting the
.include.servletPath attribute is enabled or disabled.
> Add detection of Servlet API dependencies in JSF implementation
> ---------------------------------------------------------------
>
> Key: PORTLETBRIDGE-77
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-77
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Affects Versions: 1.0.0-beta, 2.0.0-alpha
> Reporter: Neil Griffin
> Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
> Attachments: FacesUtil.java, PortletExternalContextImpl.java
>
>
> This issue was discovered when trying to use the JSR 301 RI with Liferay
> Portal.
> The Portlet spec requires the implementing portlet container (in this case,
> specifically Liferay Portal) to specify the following request attributes:
> javax.servlet.include.path_info
> javax.servlet.include.servlet_path
> Mojarra 1.2_12 is trying to determine the viewId by checking the values of
> these attributes. I would consider this to be a Servlet API dependency (or
> assumption) by Mojarra. Liferay Portal is supplying its own internal values
> for these attributes, which have no JSF viewId meaning to Mojarra. I
> submitted patches to Sun, which will appear in Mojarra 1.2_13 when it is
> released. Until then, the patch appears in nightly snapshots.
> The JSR 301 RI is aware of these servlet dependency problems in Mojarra, and
> contains some workarounds. This ticket describes an improvement that needs to
> be made to the JSR 301 RI, such that it will add detection of Servlet API
> dependencies in the JSF implementation, and only perform the workarounds if
> those dependencies are found.
> I'll attach patches to this ticket shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
