[ 
https://issues.apache.org/jira/browse/PLUTO-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neil Griffin updated PLUTO-678:
-------------------------------
    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:

{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".

  was:
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".


> TCK: Contesting V2AddlRequestTests_SPEC2_11_Render_parameters13 and 
> V3HeaderPortletTests_SPEC15_Header_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
>            Priority: Major
>             Fix For: 3.0.1
>
>
> 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:
> {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
(v7.6.3#76005)

Reply via email to