| Key: |
JS2-203
|
| Type: |
Bug
|
| Status: |
Closed
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Ate Douma
|
| Reporter: |
Ate Douma
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
j2sdk.1.4.2_04, Tomcat 5.0.28
|
|
| Resolution Date: |
28/Jan/05 09:01 AM
|
|
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"/>
|
|
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"/>
|
Show » |
|
Non-compliance to Portlet Specification PLT.16.3.3 cxxx and cxxxi (getContextPath)
While I was reinvestigating this problem because I had to document the workaround I implemented for the
Struts Bridge I determined a way to solve it generally for the Portal.
Side effect of this is that I now can remove the workaround from the Struts Bridge again (which is nice).
I fixed this by flushing the parameterMap when the wrapped request object was changed as Tomcat does
when it reuses the HttpServletRequestWrapper for an RequestDispatcher.include.