You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Eric Dalquist (JIRA)" <ji...@apache.org> on 2010/05/11 23:03:42 UTC

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

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

Eric Dalquist commented on PLUTO-590:
-------------------------------------

It looks like this is a bug in pluto per PLT.19.4.4 of the portlet 2.0 spec which states:

The following methods of the HttpServletRequest must be equivalent to the methods of the PortletRequest of similar name: getScheme, getServerName, getServerPort, getAttribute, getAttributeNames, setAttribute, removeAttribute, getLocale, getLocales, isSecure, getAuthType, getContextPath, getRemoteUser, getUserPrincipal, getRequestedSessionId, isRequestedSessionIdValid, getCookies

>  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
>             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.