Major Description
Section 25.1.1 of the Portlet 3.0 Specification titled "Query Strings in Request Dispatcher Paths" states:
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.
The DispatcherTests3S_SPEC2_19_ForwardServletRender_dispatch4 test in the Portlet 3.0 TCK attempts to test the following requirement in a RenderRequest:
The parameters associated with a PortletRequestDispatcher are scoped to apply only for the duration of the forward or include call.
It does this by creating a PortletRequestDispatcher that targets a servlet and invoking the forward(PortletRequest,PortletResponse) method:
String target = SERVLET_PREFIX + "DispatcherTests3S_SPEC2_19_ForwardServletRender_servlet" + SERVLET_SUFFIX + "?" + QUERY_STRING; PortletRequestDispatcher rd = portletConfig.getPortletContext().getRequestDispatcher(target); rd.forward(portletReq, portletResp);
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:
CompareUtils.mapsEqual("Before dispatch", oldmap, "After dispatch", newmap, tr0); tr0.writeTo(writer);
The problem is that this conflicts with Section 25.5 of the Portlet 3.0 Specification titled "The forward Method" which states:
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.
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. The proposed fix would be to save the comparison test results in a PortletSession attribute so that it could be retrieved on a successive click of the RenderURL that is output by the servlet.