[jira] [Commented] (PLUTO-671) TCK: Contesting V2AddlEnvironmentTests_SPEC2_17_EventPreferences_setValues4

["Scott Nicklous (JIRA)" <ji...@apache.org>]

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

Scott Nicklous commented on PLUTO-671:
--------------------------------------

I agree this is confusing, and I note that the corresponding test where the preference is set during processAction is coded differently:

{code:java|title=AddlEnvironmentTests_SPEC2_17_ActionPreferences.java}
      ...
      try {
         portletPrefs.setValues("tr0", (String[]) null);
         tr0.setTcSuccess(true);
      } catch (Exception e) {
         tr0.appendTcDetail(e.toString());
      }
     ...
{code}

If the EventPreferences test were coded in this way, it would just verify that the value could be set to null, which is maybe all that we need.

However, this problem brings up the larger question of how an explicitly set null value should be handled when the preference is later read. 

The JavaDoc comments are not 100% clear. Judging from the comments in getValue and getValues, a null value should cause the default value to be returned. Since setValues and setValue allow null as a value, this would imply that setting a preference value to null would have the effect of removing the preference so that the default value is returned when getValue or getValues is used. 

On the other hand, null is a valid value that is distinctly different from the preference not existing. Since setValue and setValues allow the value of null to be explicitly set, it would be reasonable to assume that an explicitly set null value can be read as such through getValue and getValues. Pluto seems to be coded in this manner, as is WebSphere.

Since this functionality is basically unchanged compared to v2.0, I think we should defer to the behavior of the existing 2.0 portals to try to get maximum convergence. If we leave the Pluto behavior as-is, the JavaDoc should be updated to be more clear.


> TCK: Contesting V2AddlEnvironmentTests_SPEC2_17_EventPreferences_setValues4
> ---------------------------------------------------------------------------
>
>                 Key: PLUTO-671
>                 URL: https://issues.apache.org/jira/browse/PLUTO-671
>             Project: Pluto
>          Issue Type: Bug
>          Components: tck
>    Affects Versions: 3.0.0
>            Reporter: Neil Griffin
>            Assignee: Scott Nicklous
>             Fix For: 3.0.1
>
>
> The Portlet 3.0 Javadoc for [PortletPreferences.getValue(String key, String def)|https://portals.apache.org/pluto/portlet-3.0-apidocs/javax/portlet/PortletPreferences.html#getValue(java.lang.String,%20java.lang.String)] states:
> {quote}If there are no preference values associated with the given key, or the backing preference database is unavailable, it returns the given default value. A null value is treated as a non-existent value.{quote}
> And the Javadoc for [PortletPreferences.getValues(String key, String\[\] def)|https://portals.apache.org/pluto/portlet-3.0-apidocs/javax/portlet/PortletPreferences.html#getValues(java.lang.String,%20java.lang.String%5B%5D)] states​:
> {quote} Returns the specified default if there is no value associated with the key, or if the backing store is inaccessible. A null value is treated as a non-existent value.{quote}
> The Javadoc for [PortletPreferences.setValue(String key, String ... values)|https://portals.apache.org/pluto/portlet-3.0-apidocs/javax/portlet/PortletPreferences.html#setValues(java.lang.String,%20java.lang.String...)] states:
> {quote}Sets a multi-valued String preference for the specified key. The key cannot be null, but null values in the values parameter are allowed. If the same key contained already a String or String[] value it must be replaced by the new value.{quote}
> ​The V2AddlEnvironmentTests_SPEC2_17_EventPreferences_setValues4 test case contains the following Java code:​
> {code:java|title=AddlEnvironmentTests_SPEC2_17_EventPreferences_event.java}
> ​portletPrefs.setValues("tr0", (String[])null);
> if (portletPrefs.getValue("tr0", "tr0") == null) {
>     tr0.setTcSuccess(true);
> }​
> {code}
> Given the language in the Javadoc, shouldn't the call to {{portletPrefs.getValue("tr0", "tr0")}} return {{"tr0"}} and not {{null}}?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)