WARNING: This server is unstable and will be retired in the next days. If you want to keep this forum available, please request immediately a migration on the Nabble Support forum. Forums that don't receive any migration request will be deleted forever.

 « Return to Thread: [jira] [Created] (PLUTO-609) PortletPreferencesImpl doesn't handle null preferences correctly

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

by JIRA jira@apache.org :: Rate this Message:

| View in Thread


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

Eric Dalquist commented on PLUTO-609:
-------------------------------------

I disagree, there is an explicit: PortletPreferences.reset(String) method which is used to reset a preference to its default value, the API does not give any way to remove a preference, only to reset it to its default value.

Also setValue states that only null keys are NOT allowed and more importantly setValues states that "null values in the values parameter are allowed." which means that if I store "new String[] {null}" that should actually be stored for me by the portal and I should be able to retrieve that value. Further more since setValue(key, value) is simply short hand for setValues(key, new String[] { value }) calling setValue(key, null) should also store a String array length 1 that contains a single null value.

This is further confirmed by PLT.17.1 which states "Preferences attributes can be set to null." and if a value is set to null it is NOT the same as "no value being associated", a null entry in an array is still a value that has been associated with the key.

I can see reverting part of the change since getValue states that "A null value is treated as a non-existent value". While getValues has the same statement I'd assume that meant the array as a whole.

Taking the javadoc of getValue into account I believe the following behavior is what should be happening:

Calling either setValue(key, null) OR setValues(key, new String[] {null}) should result in:
getValue(key, "DEFAULT") == "DEFAULT"
getValues(key, new String[] { "DEFAULT" }) = [null]

I believe this is the case since setValue(key, value) is simply short hand for setValues(key, new String[] { value }) and since a String array of length 1 has been stored getValues must return that array even though its only value is null.

> 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

       

 « Return to Thread: [jira] [Created] (PLUTO-609) PortletPreferencesImpl doesn't handle null preferences correctly