[jira] [Commented] (PLUTO-609) PortletPreferencesImpl doesn't handle null preferences correctly

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

 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira