[jira] [Created] (PLUTO-677) TCK: Contesting DispatcherTests3S_SPEC2_19_ForwardServletRender_dispatch4

["Neil Griffin (JIRA)" <ji...@apache.org>]

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)