[PLUTO-671] TCK: Contesting V2AddlEnvironmentTests_SPEC2_17_EventPreferences_setValues4

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0
• Fix Version/s: 3.0.1
• Component/s: tck
• Assignee: Scott Nicklous
• Reporter: Neil Griffin (Inactive)
• Created: 02/Dec/17 18:50
• Updated: 14/Dec/22 14:37
• Resolved: 05/Dec/17 18:37

Description

The Portlet 3.0 Javadoc for PortletPreferences.getValue(String key, String def) states:

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.

And the Javadoc for PortletPreferences.getValues(String key, String[] def) states​:

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.

The Javadoc for PortletPreferences.setValue(String key, String ... values) states:

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.

​The V2AddlEnvironmentTests_SPEC2_17_EventPreferences_setValues4 test case contains the following Java code:​

AddlEnvironmentTests_SPEC2_17_EventPreferences_event.java

​portletPrefs.setValues("tr0", (String[])null);
if (portletPrefs.getValue("tr0", "tr0") == null) {
    tr0.setTcSuccess(true);
}​

Given the language in the Javadoc, shouldn't the call to portletPrefs.getValue("tr0", "tr0") return "tr0" and not null?