You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Neil Griffin (JIRA)" <de...@myfaces.apache.org> on 2009/05/29 13:51:45 UTC
[jira] Created: (PORTLETBRIDGE-77) Add detection of Servlet API
dependencies in JSF implementation
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: Improvement
Reporter: Neil Griffin
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.
[jira] Updated: (PORTLETBRIDGE-77) Add detection of Servlet API
dependencies in JSF implementation
Posted by "Michael Freedman (JIRA)" <de...@myfaces.apache.org>.
[ 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.
[jira] Updated: (PORTLETBRIDGE-77) Add detection of Servlet API
dependencies in JSF implementation
Posted by "Neil Griffin (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Neil Griffin updated PORTLETBRIDGE-77:
--------------------------------------
Status: Patch Available (was: Open)
> 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: Improvement
> Reporter: Neil Griffin
>
> 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.
[jira] Commented: (PORTLETBRIDGE-77) Add detection of Servlet API
dependencies in JSF implementation
Posted by "Neil Griffin (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717289#action_12717289 ]
Neil Griffin commented on PORTLETBRIDGE-77:
-------------------------------------------
I too searched *.xml *.java and *.jsp for occurrences of "/invoke" and couldn't find any.
So I don't know the answer to your question, but I have a guess...
Section PLT.19.3.1 of the Portlet 2.0 spec says that the following parameters must be set:
javax.servlet.include.request_uri
javax.servlet.include.context_path
javax.servlet.include.servlet_path
javax.servlet.include.path_info
javax.servlet.include.query_string
So it might be that Liferay sets a value to "/invoke", simply to pass the TCK test suite, thus achieving compliance.
> 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: Improvement
> Reporter: Neil Griffin
> 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.