[ http://issues.apache.org/jira/browse/PB-52?page=comments#action_12461045
]
Matthew Bruzek commented on PB-52:
----------------------------------
I tried this fix and am no longer getting the IllegalArgumentException from the
JSF implementation class.
I set break points on both encodeActionURL() and encodeRenderURL() method to
evaluate your suggestion. The encodeActionURL() method is always called with
an encoded URL string parameter (in my application and environment). And
returning the string instead of calling encode again, prevents this exception.
As for the encodeRenderURL() method, the string parameter coming in is NOT
encoded. In my application (and environment) the method encodeRenderURL() is
called many times to encode local JavaScript URIs.
I was able to evaluate the original call this.portletResponse.encodeURL(s) in
the debugger, and the result was the same as the returning the string parameter
(no actual encoding was being done). In my example the string parameters are
always local references starting with the slash ("/") character. It should be
noted that encodeRenderURL() evaluates the string parameter, if the string does
not start with a slash, a slash is prepended to the string. Since there is no
difference in the two results for my tests I am OK with your the fix in this
method. However, since the String parameter is not encoded coming into this
method, it would be safe to keep the original code.
It is really up to you to keep the fix in encodeRenderURL(). The right thing
to do is to consult the JSF specification for a change like this.
Thanks for making the change to encodeActionURL() it does seem that works
better than before preventing the IllegalArgumentException from being thrown.
> 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]
