[TRINIDAD-1236] Trinidad should be able to state save non-Serializable Lists

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0.9-core, 1.2.9-core
• Fix Version/s: 1.2.10-core, 1.0.10-core
• Component/s: Components
• Environment: Any environment in which the TreeState is Serialized and a non-Serializable List implementation (such as SubList) is used. For example, client state saving or High Availability environments.
• Assignee: Jeanne Waldman
• Reporter: Blake Sullivan
• Created: 22/Sep/08 16:54
• Updated: 27/Jan/10 08:46
• Resolved: 22/Sep/08 21:18

Description

Trinidad supports state saving of component attributes by delegating to the PropertyKey implementations. For non-CAP_STATE_HOLDER, non CAP_LIST attributes, the PropertyKey assumes that simply returning the value is sufficient. If the value is Serializable, this is sufficient to support client-state saving and fail over. However, if the value is not-Serializable the Serialization process will fail when it is attempt. In particular, a problem can occur with List.class (as opposed to CAP_LIST) PropertyKeys with a non-Serializable implementation. While most common List implementations are Serializable, the implementations that AbstractList uses to implement sublist() are not.

The proposal is to change the default PropertyKey saveValue()/restoreValue() implementations to always use StateUtils.saveList(context, value); for PropertyKey's of type List.class when the instance is not a ValueExpression. Note that this won't help the more general case where the PropertyKey is of type Object.class and a List instance is used for the property value