[
https://issues.apache.org/jira/browse/PLUTO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reopened PLUTO-590:
-----------------------------
Assignee: Ate Douma (was: Eric Dalquist)
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.
