Neil Griffin created PLUTO-677:
----------------------------------
Summary: TCK: Contesting
DispatcherTests3S_SPEC2_19_ForwardServletRender_dispatch4
Key: PLUTO-677
URL: https://issues.apache.org/jira/browse/PLUTO-677
Project: Pluto
Issue Type: Bug
Components: tck
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Scott Nicklous
Fix For: 3.0.1
Section 25.1.1 of the Portlet 3.0 Specification titled "Query Strings in
Request Dispatcher Paths" states:
{quote}
The portlet container must aggregate parameters specified in the query string
used to create the PortletRequestDispatcher with the portlet render parameters.
Query string parameters take precedence over other portlet render parameters of
the same name passed to the servlet or JSP
targeted by the forward or include.
The parameters associated with a PortletRequestDispatcher are scoped to apply
only for the duration of the forward or include call.
{quote}
The DispatcherTests3S_SPEC2_19_ForwardServletRender_dispatch4 test in the
Portlet 3.0 TCK attempts to test the following requirement in a RenderRequest:
{quote}
The parameters associated with a PortletRequestDispatcher are scoped to apply
only for the duration of the forward or include call.
{quote}
It does this by creating a PortletRequestDispatcher that targets a servlet and
invoking the {{forward(PortletRequest,PortletResponse)}} method:
{code:java|title=DispatcherTests3S_SPEC2_19_ForwardServletRender.java}
String target = SERVLET_PREFIX +
"DispatcherTests3S_SPEC2_19_ForwardServletRender_servlet" + SERVLET_SUFFIX + "?"
+ QUERY_STRING;
PortletRequestDispatcher rd =
portletConfig.getPortletContext().getRequestDispatcher(target);
rd.forward(portletReq, portletResp);
{code}
It also compares the PortletRequest parameter map values before and after the
forward, attempting to ensure that the names and corresponding values are the
same. If they are different, the test attempts to write the results of the
comparison to the response:
{code:java|title=DispatcherTests3S_SPEC2_19_ForwardServletRender.java}
CompareUtils.mapsEqual("Before dispatch", oldmap, "After dispatch", newmap,
tr0);
tr0.writeTo(writer);
{code}
The problem is that this conflicts with Section 25.5 of the Portlet 3.0
Specification titled "The forward Method" which states:
{quote}
Before the RequestDispatcher interface forward method returns, the portlet
container must flush any response data to the portal application and close the
output stream for the portlet, unless the request was put into asynchronous
mode. If an error occurs in the target of a request dispatcher forward, the
exception may be propagated back through all of the calling filters and
servlets and eventually back to the portlet container.
{quote}
Although the test passes on Pluto, the test fails on Liferay Portal because
Liferay properly properly closes the output stream of the portlet after the
{{forward}} method is called.
Therefore test (as currently) designed seems to be invalid.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
