[jira] [Created] (PLUTO-678) TCK: Contesting V2AddlRequestTests_SPEC2_11_Render_parameters13
"Dante Wang (JIRA)" <[email protected]>
| Newsgroups | gmane.comp.jakarta.pluto.devel |
|---|---|
| Message-ID | <[email protected]> |
Dante Wang created PLUTO-678:
--------------------------------
Summary: TCK: Contesting V2AddlRequestTests_SPEC2_11_Render_parameters13
Key: PLUTO-678
URL: https://issues.apache.org/jira/browse/PLUTO-678
Project: Pluto
Issue Type: Bug
Components: tck
Affects Versions: 3.0.0
Reporter: Dante Wang
Assignee: Scott Nicklous
Fix For: 3.0.1
The TCK test case V2AddlRequestTests_SPEC2_11_Render_parameters13 attempts to test the following requirement as declared in Portlet Spec 3.0 chapter 11.2:
{quote}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.{quote}
It does this by first setting parameters into a render URL (the URL itself is also set as a parameter):
{code:java}
PortletURL rurl = portletResp.createRenderURL();
rurl.setParameters(portletReq.getPrivateParameterMap());
rurl.setParameter("tr2", "true");
rurl.setParameter("renderURLTr2", rurl.toString());
{code}
and then checking the parameter from RenderRequest:
{code:java}
portletReq.getParameter("renderURLTr2").contains("tr2:" + portletReq.getParameter("tr2"))
{code}
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".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)