[jira] Issue Comment Edited: (PLUTO-590) In a porltet JSP file, calling request.getContextPath() gives the portal app "/pluto" and not the portlet app's context path.

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PLUTO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871950#action_12871950 ] 

Ate Douma edited comment on PLUTO-590 at 5/26/10 5:07 PM:
----------------------------------------------------------

I have to rollback this change as it breaks Portlet 2.0 TCK tests (2x).

The solution isn't and cannot be as simple as just returning the current underlying portlet contextpath: the portlet spec is to particular in this case (and for related request path methods).
The "problem" lies in the fact that the portlet spec demands very specific semantics for especially request *forward* handling which don't "fit" with the servlet container semantics.
In addition, named servlet dispatching is even more peculiar and different from normal servlet container semantics.
For all these request dispatching, the servlet container (and thus servlet spec) only has to concern itself with an incoming "client" request coming directly from the user/browser.
However, with the portlet spec, the portal plays an intermediate role in this, causing the servlet semantics no longer to hold.

This is the reason why the HttpServletPortletRequestWrapper logic is, and is required to be, so "complicated", as even while the portlet spec imposes deviating semantics, the target/invoked servlet still must be provided with a consistent request "context" from the servlet container point of view as well.

Anyway, it might be true that the current implementation does not yet properly deal with the use-case presented by this issue (I haven't actually tested/verified yet), in which case it needs fixing for sure.
But possibly the error might also be somewhere else,  maybe within the Pluto Portal Driver itself (in Jetspeed which also uses the Pluto container I haven't encountered this issue).

I will look into this issue shortly and try to come up with a proper solution. If the problem indeed is within the container, it'll have to pass the Portlet 2.0 TCK to qualify of course. 
     

      was (Author: adouma):
    I have to rollback this change as it breaks Portlet 2.0 TCK tests (2x).

The solution isn't and cannot be as simple as just returning the current underlying servlet contextpath: the portlet spec is to particular in this case (and for related request path methods).
The "problem" lies in the fact that the portlet spec demands very specific semantics for especially request *forward* handling which don't "fit" with the servlet container semantics.
In addition, named servlet dispatching is even more peculiar and different from normal servlet container semantics.
For all these request dispatching, the servlet container (and thus servlet spec) only has to concern itself with an incoming "client" request coming directly from the user/browser.
However, with the portlet spec, the portal plays an intermediate role in this, causing the servlet semantics no longer to hold.

This is the reason why the HttpServletPortletRequestWrapper logic is, and is required to be, so "complicated", as even while the portlet spec imposes deviating semantics, the target/invoked servlet still must be provided with a consistent request "context" from the servlet container point of view as well.

Anyway, it might be true that the current implementation does not yet properly deal with the use-case presented by this issue (I haven't actually tested/verified yet), in which case it needs fixing for sure.
But possibly the error might also be somewhere else,  maybe within the Pluto Portal Driver itself (in Jetspeed which also uses the Pluto container I haven't encountered this issue).

I will look into this issue shortly and try to come up with a proper solution. If the problem indeed is within the container, it'll have to pass the Portlet 2.0 TCK to qualify of course. 
     
  
>  In a porltet JSP file, calling request.getContextPath() gives the portal app "/pluto" and not the portlet app's context path.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PLUTO-590
>                 URL: https://issues.apache.org/jira/browse/PLUTO-590
>             Project: Pluto
>          Issue Type: Bug
>    Affects Versions: 2.0.0
>            Reporter: Luis
>            Assignee: Ate Douma
>             Fix For: 2.0.2, 2.1.0
>
>
> JSPs called by a portlet have this problem.  request.getContextPath() changed between pluto 1.x and 2.0
> You need to use the portlet taglib to get the context path from the portletrequest.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.