[
https://issues.apache.org/jira/browse/PLUTO-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104812#comment-13104812
]
Ate Douma commented on PLUTO-609:
---------------------------------
Looking further into both the code for the test *and* the javadoc for the
PortletPreferences#getValue and #getValues methods, I think the previous
behavior, returning the provided defaultValue(s) when either no *or* null
values were retrieved for the preference, actually was correct. That is:
according to the specification.
The javadoc says (for both methods):
"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."
This can be read as: if existing preference values are overridden with a null
value array, this should be treated as "removing" the current values for the
preference (making it "non-existent").
The current TCK tests use a "default" portletpreference configuration in the
portlet.xml where the key (preferredLanguage or preferredLanguages) is defined,
but without any value (e.g. non-existent *or* null, no way to distinguish these
two), and expect the provided default value(s) on the #getValue and #getValues
methods to be returned then instead.
While this could be debated if it actually is the desired behavior, as this
effectively makes it impossible to explicitly store a NULL value for a
preference, not to be "overridden" by a provided default value,
that use-case isn't supported by the specification. And, as we at least should
abide to the specification, I think the change implemented by the issue should
be reverted.
> PortletPreferencesImpl doesn't handle null preferences correctly
> ----------------------------------------------------------------
>
> Key: PLUTO-609
> URL: https://issues.apache.org/jira/browse/PLUTO-609
> Project: Pluto
> Issue Type: Bug
> Affects Versions: 2.0.2
> Reporter: Eric Dalquist
> Assignee: Ate Douma
> Fix For: 2.0.3, 2.1.0
>
>
> PLT.17.1 states "Preference attributes are String array objects. Preferences
> attributes can be set to null." In Pluto if you call
> PortletPreference.setValue("name", null), PortletPreference.setValues("name",
> String[] {null}), or PortletPreference.setValues("name", null) the correct
> data is passed to the underlying preference storage SPI.
> The problem is when calling getValue("name", "DEFAULT") or getValues("name",
> new String[] { "DEFAULT" }) for any of the three previous cases "DEFAULT" is
> returned. From my reading of the spec this is not correct as in each case the
> preference has been set but with a single null value or a null values array.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
