Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0-dev/cvs, 2.0-a1, 2.0-M1
-
None
-
j2sdk.1.4.2_04, Tomcat 5.0.28
Description
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"/>