[ http://issues.apache.org/jira/browse/PB-52?page=comments#action_12461112 ] Matthew Bruzek commented on PB-52: ----------------------------------
After further thought and reading specification and Javadoc, perhaps we should be more careful about this fix: The JSF 1.2 specification ( http://jcp.org/aboutJava/communityprocess/final/jsr252/index.html ) tells us that encodeActionURL() and encodeResourceURL() return a URL that correctly identifies the resource, and to look to the Javadoc for more details. In my environment the string passed in to encodeActionURL() already identified a valid resource and needed no further encoding. The JSF Javadoc ( http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/context/ExternalContext.html ) for both encodeActionURL() and encodeResourceURL() instructs portlet implementations to return the value returned by the javax.portlet.PortletResponse method encodeURL(url), which the original code was doing correctly. However this was causing an IllegalArgumentException with the Websphere implementation because the URL was already encoded. I looked more closely at the exception, and it was because "only absolute URLs or full path URIs are allowed" because the string didn't start with "/" (the slash character), or "http://"; or "https://";. Perhaps a better solution (for both methods) would be to only encode the string if the parameter is an absolute URL or relative URI. In the other case, return the original parameter. This would fix both cases, unless in your tests encodeActionURL() was being called with an encoded URI that was absolute or relative. In my environment encodeActionURL() is always called with an encoded URL that is neither absolute nor relative. > JSF portal bridge attempting to encode URL twice fails > ------------------------------------------------------ > > Key: PB-52 > URL: http://issues.apache.org/jira/browse/PB-52 > Project: Portals Bridges > Issue Type: Bug > Components: jsf > Affects Versions: 1.0 > Environment: Sun JSF Reference Implementation version 1.2 > (jsf-impl.jar) > Websphere portlet container version 6.1.0 > Apache MyFaces JSF portal bridge version 1.0 (portals-bridges-jsf-1.0.jar) > Reporter: Matthew Bruzek > Assigned To: David Sean Taylor > > I evaluating the MyFaces portlet bridge with a sample JSF portal app and I > ran into a problem. The portlet worked with the Sun portlet bridge, but does > not even complete the render phase when I try to use the MyFaces portlet > bridge. > The exception I am seeing is: > javax.servlet.ServletException: only absolute URLs or full path URIs are > allowed > Caused by: java.lang.IllegalArgumentException: only absolute URLs or full > path URIs are allowed > at > com.ibm.ws.portletcontainer.core.impl.PortletResponseImpl.encodeURL(PortletResponseImpl.java:143) > at > org.apache.portals.bridges.jsf.PortletExternalContextImpl.encodeActionURL(PortletExternalContextImpl.java) > I hooked up a remote debugger to see what was happening. The String URL that > is passed into PortletExternalContextImpl is: > pa.do?_pa=-1088437171&_rid=-507a2aba:10f977651ed:-7fee&.pa=true > As you can see the URL is already encoded and the encodeActionURL( String ) > method attempts to call this.portletResponse.encodeURL(s). The > PortletResponse tries to encode the string URL again, leading to the > Exception. > I tracked down the difference in Sun's version of ExternalContextImpl. I > found a Sun portlet bridge bug # 6243708 that addresses the same problem of > double encoding the value from the portlet environment. The Sun portlet > bridge fixed this bug in their > com.sun.faces.portlet.ExternalContextImpl.encodeActionURL( String ) method to > return the string url instead of attempting to encode it again. > I suggest that the PortletExternalContextImpl will always get portal encoded > URL strings, and should return the string passed to it to avoid this > Exceptional case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
