You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Michael Freedman (JIRA)" <de...@myfaces.apache.org> on 2011/08/23 19:28:29 UTC
[jira] [Created] (PORTLETBRIDGE-219) NonFaces in protocol resource
request fails after and action
NonFaces in protocol resource request fails after and action
------------------------------------------------------------
Key: PORTLETBRIDGE-219
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-219
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
Impl relies on the same render parameter to hold the viewId at the end of an action or in a resourceURL that references a Faces resource. Hence the check in Bridge during a resource request on whether the request is for a Faces or NonFaces resource depends on whether this render parameter exists or not. The problem is in that in a resource URL this isn't really a render parameter but rather a resource parameter. The resource receives the current portlet render parameters + its url encoded resource parameters. This means that if an action occurs it will set the VIEWID render parameter. If in the render following this action we create and render a resource url to a nonFaces resource request then when this resource request is sent we will still receive the VIEWID parameter and incorrectly think this is Faces resource request when its a nonFaces one.
Fix is to have a distinct resource param to hold the viewId for Faces resource URL. Then the check looks for existence/nonexistence of this param and ignores whether the render param VIEWID is there. Note: when making this fix will also need to update the code that resolves the view to execute as we will need to test if we are in a resource request and pull from the right param.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-219) NonFaces in protocol
resource request fails after and action
Posted by "Michael Freedman (Commented) (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155498#comment-13155498 ]
Michael Freedman commented on PORTLETBRIDGE-219:
------------------------------------------------
Fixed in the 2.0 Trunk and oracle branches by adding the distinct resource param to hold the viewId. Work still pending in the 3.0 Trunk.
> NonFaces in protocol resource request fails after and action
> ------------------------------------------------------------
>
> Key: PORTLETBRIDGE-219
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-219
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 2.0.0, 3.0.0-alpha
> Reporter: Michael Freedman
> Assignee: Michael Freedman
>
> Impl relies on the same render parameter to hold the viewId at the end of an action or in a resourceURL that references a Faces resource. Hence the check in Bridge during a resource request on whether the request is for a Faces or NonFaces resource depends on whether this render parameter exists or not. The problem is in that in a resource URL this isn't really a render parameter but rather a resource parameter. The resource receives the current portlet render parameters + its url encoded resource parameters. This means that if an action occurs it will set the VIEWID render parameter. If in the render following this action we create and render a resource url to a nonFaces resource request then when this resource request is sent we will still receive the VIEWID parameter and incorrectly think this is Faces resource request when its a nonFaces one.
> Fix is to have a distinct resource param to hold the viewId for Faces resource URL. Then the check looks for existence/nonexistence of this param and ignores whether the render param VIEWID is there. Note: when making this fix will also need to update the code that resolves the view to execute as we will need to test if we are in a resource request and pull from the right param.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira