[jira] Resolved: (PORTLETBRIDGE-12) PortletViewHandler - viewId handling

["Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott O'Bryan resolved PORTLETBRIDGE-12.
----------------------------------------

    Resolution: Fixed

This has been checked in.  Thanks guys for all your work on this issue.  :)

> 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
>            Assignee: Scott O'Bryan
>            Priority: Critical
>             Fix For: 1.0.0-SNAPSHOT
>
>         Attachments: Patch01.patch
>
>
> 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.