myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan (JIRA)" <>
Subject [jira] Commented: (PORTLETBRIDGE-12) PortletViewHandler - viewId handling
Date Mon, 12 Nov 2007 23:54:50 GMT


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:
>             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
>            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/
> ===================================================================
> --- impl/src/main/java/org/apache/myfaces/portlet/faces/application/
Tue Nov 06 13:22:08 CET 2007
> +++ impl/src/main/java/org/apache/myfaces/portlet/faces/application/
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.

View raw message