[
https://issues.apache.org/jira/browse/PLUTO-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin closed PLUTO-678.
------------------------------
Resolution: Fixed
Assignee: Neil Griffin (was: Scott Nicklous)
Fixed in commit
[66e71831cb17e36f1a314c112e80f766e6bb9cbe|https://github.com/apache/portals-pluto/commit/66e71831cb17e36f1a314c112e80f766e6bb9cbe]
> 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: Neil Griffin
> 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)
