[
https://issues.apache.org/jira/browse/PLUTO-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reopened PLUTO-609:
-----------------------------
Assignee: Ate Douma (was: Eric Dalquist)
I just ran the JSR-286 TCK against the pluto 2.0.3 branch as sanity check to
validate if its still compliant before we can start the release process, and it
failed on two PortletPreferences checks.
It seems the changes introduced by this issue are not compliant with the
specification, or the TCK tests are not, this first needs further review.
> 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
