You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-dev@portals.apache.org by "Matthew Bruzek (JIRA)" <br...@portals.apache.org> on 2006/12/19 17:32:21 UTC
[jira] Created: (PB-52) JSF portal bridge attempting to encode URL
twice fails
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
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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Work started: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-52?page=all ]
Work on PB-52 started by David Sean Taylor.
> 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "Matthew Bruzek (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462528 ]
Matthew Bruzek commented on PB-52:
----------------------------------
I have tried the code changed for this bug and it works in my environment. Aside from the redundant startsWith( "http" ) I think that is how the code should work.
Thanks.
> JSF portal bridge attempting to encode URL twice fails
> ------------------------------------------------------
>
> Key: PB-52
> URL: https://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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "Matthew Bruzek (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462058 ]
Matthew Bruzek commented on PB-52:
----------------------------------
Absolute URLs will start with "http://" or "https://" because they do not depend upon any context path. For example: "http://www.google.com"
Relative URI is a string that starts with a slash ("/") character the implementation can then prepend the full path to the string. For example: "/intl/en_ALL/images/logo.gif" the context path could be prepended to create" http://www.google.com/intl/en_ALL/images/logo.gif"
The reason I get this exception is because the string from my environment was an encoded URL and did not match either of these conditions. The implementation did not know how to handle the encoded string "pa.do?_pa=-1088437171&_rid=-507a2aba:10f977651ed:-7fee&.pa=true".
The code in PortletExternalContextImpl.encodeResourceURL(String s) does some similar checking for "http" or the slash ("/") but it prepend the slash character to strings that fail this check (which I believe to be in error). These methods should NOT prepend any characters to the string unless it is specifically called out in the specifications. I would suggest changing encodeResourceURL() and encodeActionURL() to do the following for both methods:
If the string parameter starts with "http://" or "https://" or "/" then call the implementation's encodeURL() method to properly encode the strings that the implementation can handle. Otherwise return the original string as it does not need encoding, and would generate an exception if encoding was attempted.
I think this is a better solution than always returning the original string. This solution will prevent the exception from occuring in my environment and keep the methods working as designed for other possible situations.
> JSF portal bridge attempting to encode URL twice fails
> ------------------------------------------------------
>
> Key: PB-52
> URL: https://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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-52?page=comments#action_12460626 ]
David Sean Taylor commented on PB-52:
-------------------------------------
seems to work fine on all my tests here.
please test and let me know if it works for you
> 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Resolved: (PB-52) JSF portal bridge attempting to encode URL
twice fails
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Sean Taylor resolved PB-52.
---------------------------------
Resolution: Fixed
patch applied and teste by reported
> JSF portal bridge attempting to encode URL twice fails
> ------------------------------------------------------
>
> Key: PB-52
> URL: https://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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Assigned: (PB-52) JSF portal bridge attempting to encode URL
twice fails
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-52?page=all ]
David Sean Taylor reassigned PB-52:
-----------------------------------
Assignee: David Sean Taylor
> 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-52?page=comments#action_12460623 ]
David Sean Taylor commented on PB-52:
-------------------------------------
Let me try it out and see what kind of results I get here.
We should probably be doing the same for encodeRenderURL
> 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461820 ]
David Sean Taylor commented on PB-52:
-------------------------------------
Just so its clear, could you explain what you mean by an absolute *URL*, and relative *URI* along with an example of each...
> 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-52?page=comments#action_12460607 ]
David Sean Taylor commented on PB-52:
-------------------------------------
It seems kind of pointless to have this method if it does nothing
I have seen the MyFaces bridge working fine with actionURLs, but perhaps we never call the encode method
I need to leave this open until I can find more time to review and test it
> 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "Matthew Bruzek (JIRA)" <br...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/PB-52?page=comments#action_12460608 ]
Matthew Bruzek commented on PB-52:
----------------------------------
I agree it is pointless to have a method that does nothing. And I hope you can look in to this problem more.
I believe that the encodeActionURL() method is intended for ExternalContextImpl when there is no portal environment (servlets, jsps, etc). In the Portal environment the class PortalExternalContextImpl will always get an encoded url and have a problem when the PortletResponse tries to encode it.
Thanks for looking into this.
> 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "Matthew Bruzek (JIRA)" <br...@portals.apache.org>.
[ 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-52) JSF portal bridge attempting to encode
URL twice fails
Posted by "Matthew Bruzek (JIRA)" <br...@portals.apache.org>.
[ 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: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org