[PLUTO-678] TCK: Contesting V2AddlRequestTests_SPEC2_11_Render_parameters13 and V3HeaderPortletTests_SPEC15_Header_parameters13

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0
• Fix Version/s: 3.0.1
• Component/s: tck
• Assignee: Neil Griffin (Inactive)
• Reporter: Dante Wang
• Created: 10/Jan/18 02:18
• Updated: 14/Dec/22 14:37
• Resolved: 02/Feb/18 18:00

Description

The TCK test cases V2AddlRequestTests_SPEC2_11_Render_parameters13 and V3HeaderPortletTests_SPEC15_Header_parameters13 attempt to test the following requirement as declared in Portlet Spec 3.0 chapter 11.2:

If a portlet receives a render request that is the result of invoking a render URL targeting this portlet the render parameters received with the render request must be the parameters set on the render URL.

It does this by first setting parameters into a render URL (the URL itself is also set as a parameter):

PortletURL rurl = portletResp.createRenderURL();
rurl.setParameters(portletReq.getPrivateParameterMap());
rurl.setParameter("tr2", "true");
rurl.setParameter("renderURLTr2", rurl.toString());

and then checking the parameter from RenderRequest:

portletReq.getParameter("renderURLTr2").contains("tr2:" + portletReq.getParameter("tr2"))

The problem is, the checking logic assumes the parameter in a URL is represented in the form "parameterName:parameterValue", which is the case for Pluto. However, in Liferay, this logic fail because Liferay uses the form "parameterName=parameterValue".