[
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)
