portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@jakarta.apache.org>
Subject [jira] Closed: (JS2-203) Non-compliance to Portlet Specification PLT.16.3.3 cxxx and cxxxi (getContextPath)
Date Fri, 28 Jan 2005 00:12:17 GMT
     [ http://issues.apache.org/jira/browse/JS2-203?page=history ]
     
Ate Douma closed JS2-203:
-------------------------

    Resolution: Fixed

> Non-compliance to Portlet Specification  PLT.16.3.3  cxxx and cxxxi (getContextPath)
> ------------------------------------------------------------------------------------
>
>          Key: JS2-203
>          URL: http://issues.apache.org/jira/browse/JS2-203
>      Project: Jetspeed 2
>         Type: Bug
>   Components: Container
>     Versions: 2.0-dev/cvs, 2.0-a1, 2.0-M1
>  Environment: j2sdk.1.4.2_04, Tomcat 5.0.28
>     Reporter: Ate Douma
>     Assignee: Ate Douma
>      Fix For: 2.0-dev/cvs, 2.0-M2, 2.0-FINAL

>
> PLT.16.3.3 Request and Response objects for Included Servlets/JSPs
> cxxx:
> The following methods of the HttpServletRequest must return the path and query
> string information used to obtain the PortletRequestDispatcher object:
> getPathInfo, getPathTranslated, getQueryString, getRequestURI and
> getServletPath.
> cxxxi:
> 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.
> Of the above the cxxx as a whole and getContextPath of cxxxi are not implemented: 
> they return information retrieved from the original HttpRequestContext of the Portal
when run under Tomcat.
> Especially for the contextPath this has a major consequence:
> Within a Servlet (jsp, velocity et cetera) dispatched from a Portlet all relative resources
and urls point
> back to the Portal application.
> The LoginPortlet and the ChangePasswordPortlet currently make "use" of this by providing
href links to the user
> for login and logout which point directly to Servlets within the portal (web) application.
> Romain Bisse reported on the list having problems with this though when running Jetspeed-2
on WebLogic.
> Initially I thought WebLogic was in violation of the specs, but after looking deeper
at it, I discovered 
> the above problem.
> I'm going to implement the Portlet Specification requirements (of course) which also
means the LoginPortlet and
> ChangePasswordPortlet have to be changed to provide a correct href links for login and
logout again.
> Very important to understand for all developers is the change in behavior this will give
(for the better I think):
> - All (context) relative urls defined within a dispatched Servlet from a Portlet will
now be relative to its real
>   web application context.
> - All (context) relative urls defined within such a Servlet which are expected to be
relative to the Portal context
>   will have to be redefined.
>   An example for rendering an url relative to the portal context using jstl:
>   <c_rt:set var="requestContext" value="<%=request.getAttribute(RequestContext.REQUEST_PORTALENV)%>"/>
>   <c:url context="${requestContext.request.contextPath}" value="/login/logout"/>

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message