[ 
https://issues.apache.org/jira/browse/PLUTO-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395285#comment-16395285
 ] 

Scott Nicklous commented on PLUTO-697:
--------------------------------------

I agree that [BaseURL.setParameter(String, 
String[])|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/BaseURL.html#setParameter(java.lang.String,%20java.lang.String%5B%5D)]
 should throw an exception if the the values aray is null. However,  
[BaseURL.setParameter(String, 
String)|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/BaseURL.html#setParameter(java.lang.String,%20java.lang.String%5B%5D)]
 should not; rather, the parameter should be removed. 

The following code:

{{      PortletURL rurl = response.createRenderURL();}}
{{      rurl.setParameter("urlparm1", "val1");}}
{{      rurl.setParameter("urlparm2", "notnull");}}
{{      rurl.setParameter("urlparm4", new String[] \{"notnull"});}}
{{      }}
{{      try {}}
{{   {color:#14892c}      rurl.setParameter("urlparm2", (String)null);{color}}}
{{         rurl.setParameter("urlparm3", "urlparm2 should be gone.");}}
{{      } catch (Exception e) {}}
{{         rurl.setParameter("urlparm3", "Exception: " + e.toString());}}
{{      }}}

{{      try {}}
{{    {color:#FF0000}     rurl.setParameter("urlparm4", 
(String[])null);{color}}}
{{         rurl.setParameter("urlparm5", "urlparm4 should be gone.");}}
{{      } catch (Exception e) {}}
{{         rurl.setParameter("urlparm5", "Exception: " + e.toString());}}
{{      }}}

should result in parameter "urlparm2" being removed from the url when the line 
in green is executed and an exception being thrown when the line in red is 
executed.

Also, I believe the proposed clarification for v3.0 is incorrect, since v3 
defines both null and the empty array to be valid values (See: 
[setValue(java.lang.String,%20java.lang.String) 
|http://portals.apache.org/pluto/portlet-3.0-apidocs/javax/portlet/MutablePortletParameters.html#setValue(java.lang.String,%20java.lang.String)]and
 [setValues(java.lang.String,%20java.lang.String...) 
|http://portals.apache.org/pluto/portlet-3.0-apidocs/javax/portlet/MutablePortletParameters.html#setValues(java.lang.String,%20java.lang.String...)]).

Scott

> Spec: Error in Section A.3.2 titled "Clarifications that may make V1.0 
> Portlets Non-compliant"
> ----------------------------------------------------------------------------------------------
>
>                 Key: PLUTO-697
>                 URL: https://issues.apache.org/jira/browse/PLUTO-697
>             Project: Pluto
>          Issue Type: Bug
>          Components: spec
>    Affects Versions: 3.0.0
>            Reporter: Neil Griffin
>            Assignee: Scott Nicklous
>            Priority: Major
>
> Section A.3.2 of the Portlet 3.0 Specification titled "Clarifications that 
> may make V1.0 Portlets Non-compliant" states the following:
> {quote}
> PortletURL.setParameter called with a null value as value did throw an 
> IllegalStateException whereas in V2.0 it results in removing that parameter 
> from the PortletURL.
> {quote}
> This sentence is not found in the Portlet 2.0 Specification but was added in 
> the Portlet 3.0 Specification.
> The reason why this sentence was added was because:
> 1) The Portlet 1.0 Javadoc for 
> [PortletURL.setParameter(String,String)|https://portals.apache.org/pluto/portlet-1.0-apidocs/javax/portlet/PortletURL.html#setParameter(java.lang.String,%20java.lang.String)]
>  and 
> [PorteltURL.setParameter(String,String\[\])|https://portals.apache.org/pluto/portlet-1.0-apidocs/javax/portlet/PortletURL.html#setParameter(java.lang.String,%20java.lang.String%5B%5D)]
>  state the following:
> {quote}
> Throws:
> java.lang.IllegalArgumentException - if name or values are null.
> {quote}
> *AND*
> 2) The Portlet 2.0 Javadoc for [BaseURL.setParameter(String, 
> String)|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/BaseURL.html#setParameter(java.lang.String,%20java.lang.String)]
>  and [BaseURL.setParameter(String, 
> String\[\])|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/BaseURL.html#setParameter(java.lang.String,%20java.lang.String%5B%5D)]
>  was changed to this:
> {quote}
> Throws:
> java.lang.IllegalArgumentException - if name is null.
> {quote}
> *AND*
> 3) The Portlet 2.0 Javadoc for [BaseURL.setParameter(String, 
> String)|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/BaseURL.html#setParameter(java.lang.String,%20java.lang.String)]
>  states:
> {quote}
> A parameter value of null indicates that this parameter should be removed.
> {quote}
> *HOWEVER*
> 4) The Portlet 2.0 Javadoc for [BaseURL.setParameter(String, 
> String\[\])|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/BaseURL.html#setParameter(java.lang.String,%20java.lang.String%5B%5D)]
>  *does not* state that. In addition, the legacy Portlet 2.0 TCK 
> SetParameterWithValuesIllegalArgumentExceptionTestPortlet continued to expect 
> that {{IllegalArgumentException}} be thrown (the Portlet 1.0 documented 
> behavior) rather than the parameter being removed (the Portlet 2.0 documented 
> behavior).
> *In the final analysis*, if an implementor of the Portlet 2.0 API wanted to 
> be compliant with the TCK, then it had to pass 100%  of the TCK tests. This 
> means that Apache Pluto 2.0 (the Reference Implementation) and portal vendors 
> like IBM and Liferay had to throw {{IllegalArgumentException}} (the Portlet 
> 1.0 behavior). It also means that developers writing portlets for the Portlet 
> 2.0 API were never able to use the feature of removing a parameter by passing 
> {{null}}.
> In order to remedy the contradictions, the Portlet 3.0 Specification text 
> should be moved to a new section titled "Clarifications that may make V2.0 
> Portlets Non-compliant", changing "V2.0" to "V3.0" like the following:
> {quote}
> PortletURL.setParameter called with a null value as value did throw an 
> IllegalStateException whereas in V3.0 it results in removing that parameter 
> from the PortletURL.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to