[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541994
]
Scott O'Bryan commented on PORTLETBRIDGE-12:
--------------------------------------------
Hey Bernhard, I'm going to assume the "official" patch for this does not simply
change "xhml" to "jsf"?
> PortletViewHandler - viewId handling
> ------------------------------------
>
> Key: PORTLETBRIDGE-12
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-12
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-SNAPSHOT
> Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT
> (locally patched version)
> Reporter: Bernhard Huemer
> Priority: Critical
>
> While restoring a view JSF tries to determine the view ID by using some
> request information (i.e. request path and path info). However, a JSF portlet
> bridge has to use a different approach to "save" the view ID (because of the
> portlet environment) and therefore the PortletViewHandler intercepts
> getActionURL in order to save the view ID as url argument. During the next
> request the PortletExternalContext simulates the appropriate request info
> using this view ID (see PortletExternalContextImpl.mapPathsFromViewId). The
> problem is that the PortletViewHandler doesn't save the correct version of
> the view ID.
> The following example shoud illustrate why the view ID is incorrect.
> Default View ID: /index.jsf, Default Suffix: .xhtml
> As I've already said, the PortletViewHandler saves the view ID as url
> argument. Actually the PortletExternalContext is responsible for saving url
> parameters, but the PortletViewHandler determines the view ID to save (see
> PortletViewHandler.getActionURL). However, the PortletViewHandler saves the
> given view ID (i.e. the given parameter - just remember the signature of
> getActionURL) which results in the following url:
> /<context-name>/index.jsf?_VIEW_ID=/index.xhtml
> During the next request the PortletExternalContext tries to map the path
> information by using this view ID (I know that I'm repeating myself ;-)). In
> order to so, it iterates over all servlet mappings to determine the proper
> request information. This attempt fails, however, as no Faces Servlet has
> been mapped to *.xhtml. As a last resort the PortletExternalContext assumes
> that the given view ID can be used as path info. The outcome of this is:
> request path = null
> path info = /index.xhtml
> However, JSF would expect the following request information in order to
> restore the appropriate view:
> request path = /index.jsf
> path info = null
> I've resolved the bug by saving the "external" view ID (don't know if there's
> any special name for it, for example /index.jsf instead of /index.xhtml), at
> least it works here, but my patch is rather "provisional" as I've just done
> the following:
> Index:
> impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
> ===================================================================
> ---
> impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
> Tue Nov 06 13:22:08 CET 2007
> +++
> impl/src/main/java/org/apache/myfaces/portlet/faces/application/PortletViewHandlerImpl.java
> Tue Nov 06 13:22:08 CET 2007
> @@ -127,7 +127,7 @@
> // attribute
> {
> actionURL = URLUtils.appendURLArguments(actionURL, new String[] {
> - PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER, viewId });
> + PortletExternalContextImpl.VIEW_ID_QUERY_PARAMETER,
> viewId.replace("xhtml", "jsf") });
> }
>
> return actionURL;
> I'll create an appropriate version of this "patch" next week, if no one else
> wants to take a look at it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
