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/28 23:02:21 UTC
[jira] Created: (PB-54) PortletViewHandlerImpl.getResourceURL()
always prepends the context path.
PortletViewHandlerImpl.getResourceURL() always prepends the context path.
-------------------------------------------------------------------------
Key: PB-54
URL: http://issues.apache.org/jira/browse/PB-54
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
When running an application on the MyFaces JSF portal bridge, I noticed the context path is always appended to the URI path in PortletViewHandlerImpl.getResourceURL() even if the path parameter already contains the context path.
My JSF portal application loads image resources and css files and when using the Sun portal bridge all the resources resolved. When attempt to use the MyFaces JSF portal bridge, the application failed to find the resources citing a java.io.FileNotFoundException for the resources. The resources that already contained the context path are prepened with another context path. The getResourceURL() method of PortletViewHandlerImpl ALWAYS prepends the context path to the path parameter without checking if it is already there.
I believe changing the getResourceURL() code to delegate this call to the handler.getResourceURL() method of (javax.faces.application.ViewHandler) would resolve the problem. I made this small change in my sandbox. The URLs with the context path did not get prepended and the application found all resources.
Is there a reason the PortletViewHandlerImpl does not delegate the getResourceURL() method that I am missing? If there is not a compelling reason not to delegate the call to the included ViewHandler, then perhaps we should delegate the call to javax.faces.application.ViewHandler. If there is a compelling reason perhaps we should add a check if the context path already exists in the path parameter.
--
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-54) PortletViewHandlerImpl.getResourceURL()
always prepends the context path.
Posted by "Matthew Bruzek (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462526 ]
Matthew Bruzek commented on PB-54:
----------------------------------
I have tried the code in the SVN trunk for this fix and it works for my environment.
Thanks.
> PortletViewHandlerImpl.getResourceURL() always prepends the context path.
> -------------------------------------------------------------------------
>
> Key: PB-54
> URL: https://issues.apache.org/jira/browse/PB-54
> 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
>
> When running an application on the MyFaces JSF portal bridge, I noticed the context path is always appended to the URI path in PortletViewHandlerImpl.getResourceURL() even if the path parameter already contains the context path.
> My JSF portal application loads image resources and css files and when using the Sun portal bridge all the resources resolved. When attempt to use the MyFaces JSF portal bridge, the application failed to find the resources citing a java.io.FileNotFoundException for the resources. The resources that already contained the context path are prepened with another context path. The getResourceURL() method of PortletViewHandlerImpl ALWAYS prepends the context path to the path parameter without checking if it is already there.
> I believe changing the getResourceURL() code to delegate this call to the handler.getResourceURL() method of (javax.faces.application.ViewHandler) would resolve the problem. I made this small change in my sandbox. The URLs with the context path did not get prepended and the application found all resources.
> Is there a reason the PortletViewHandlerImpl does not delegate the getResourceURL() method that I am missing? If there is not a compelling reason not to delegate the call to the included ViewHandler, then perhaps we should delegate the call to javax.faces.application.ViewHandler. If there is a compelling reason perhaps we should add a check if the context path already exists in the path parameter.
--
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-54) PortletViewHandlerImpl.getResourceURL()
always prepends the context path.
Posted by "Matthew Bruzek (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462076 ]
Matthew Bruzek commented on PB-54:
----------------------------------
For example of the problem one of the resource string is "/Graph/theme/graphStyle.css" and the result of getRequestContextPath() is "/Graph" so the resulting string that is returned is "/Graph/Graph/theme/graphStyle.css" and that resource is not found.
The method getResourceURL() should not always prepend the context path in this case.
> PortletViewHandlerImpl.getResourceURL() always prepends the context path.
> -------------------------------------------------------------------------
>
> Key: PB-54
> URL: https://issues.apache.org/jira/browse/PB-54
> 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
>
> When running an application on the MyFaces JSF portal bridge, I noticed the context path is always appended to the URI path in PortletViewHandlerImpl.getResourceURL() even if the path parameter already contains the context path.
> My JSF portal application loads image resources and css files and when using the Sun portal bridge all the resources resolved. When attempt to use the MyFaces JSF portal bridge, the application failed to find the resources citing a java.io.FileNotFoundException for the resources. The resources that already contained the context path are prepened with another context path. The getResourceURL() method of PortletViewHandlerImpl ALWAYS prepends the context path to the path parameter without checking if it is already there.
> I believe changing the getResourceURL() code to delegate this call to the handler.getResourceURL() method of (javax.faces.application.ViewHandler) would resolve the problem. I made this small change in my sandbox. The URLs with the context path did not get prepended and the application found all resources.
> Is there a reason the PortletViewHandlerImpl does not delegate the getResourceURL() method that I am missing? If there is not a compelling reason not to delegate the call to the included ViewHandler, then perhaps we should delegate the call to javax.faces.application.ViewHandler. If there is a compelling reason perhaps we should add a check if the context path already exists in the path parameter.
--
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-54) PortletViewHandlerImpl.getResourceURL()
always prepends the context path.
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Sean Taylor reassigned PB-54:
-----------------------------------
Assignee: David Sean Taylor
> PortletViewHandlerImpl.getResourceURL() always prepends the context path.
> -------------------------------------------------------------------------
>
> Key: PB-54
> URL: https://issues.apache.org/jira/browse/PB-54
> 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
> Fix For: 1.0.1
>
>
> When running an application on the MyFaces JSF portal bridge, I noticed the context path is always appended to the URI path in PortletViewHandlerImpl.getResourceURL() even if the path parameter already contains the context path.
> My JSF portal application loads image resources and css files and when using the Sun portal bridge all the resources resolved. When attempt to use the MyFaces JSF portal bridge, the application failed to find the resources citing a java.io.FileNotFoundException for the resources. The resources that already contained the context path are prepened with another context path. The getResourceURL() method of PortletViewHandlerImpl ALWAYS prepends the context path to the path parameter without checking if it is already there.
> I believe changing the getResourceURL() code to delegate this call to the handler.getResourceURL() method of (javax.faces.application.ViewHandler) would resolve the problem. I made this small change in my sandbox. The URLs with the context path did not get prepended and the application found all resources.
> Is there a reason the PortletViewHandlerImpl does not delegate the getResourceURL() method that I am missing? If there is not a compelling reason not to delegate the call to the included ViewHandler, then perhaps we should delegate the call to javax.faces.application.ViewHandler. If there is a compelling reason perhaps we should add a check if the context path already exists in the path parameter.
--
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] Resolved: (PB-54) PortletViewHandlerImpl.getResourceURL()
always prepends the context path.
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Sean Taylor resolved PB-54.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.0.1
patch applied and tested by reporter
> PortletViewHandlerImpl.getResourceURL() always prepends the context path.
> -------------------------------------------------------------------------
>
> Key: PB-54
> URL: https://issues.apache.org/jira/browse/PB-54
> 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
> Fix For: 1.0.1
>
>
> When running an application on the MyFaces JSF portal bridge, I noticed the context path is always appended to the URI path in PortletViewHandlerImpl.getResourceURL() even if the path parameter already contains the context path.
> My JSF portal application loads image resources and css files and when using the Sun portal bridge all the resources resolved. When attempt to use the MyFaces JSF portal bridge, the application failed to find the resources citing a java.io.FileNotFoundException for the resources. The resources that already contained the context path are prepened with another context path. The getResourceURL() method of PortletViewHandlerImpl ALWAYS prepends the context path to the path parameter without checking if it is already there.
> I believe changing the getResourceURL() code to delegate this call to the handler.getResourceURL() method of (javax.faces.application.ViewHandler) would resolve the problem. I made this small change in my sandbox. The URLs with the context path did not get prepended and the application found all resources.
> Is there a reason the PortletViewHandlerImpl does not delegate the getResourceURL() method that I am missing? If there is not a compelling reason not to delegate the call to the included ViewHandler, then perhaps we should delegate the call to javax.faces.application.ViewHandler. If there is a compelling reason perhaps we should add a check if the context path already exists in the path parameter.
--
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