[
https://issues.apache.org/jira/browse/TRINIDAD-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Sullivan updated TRINIDAD-1236:
-------------------------------------
Status: Open (was: Patch Available)
> Trinidad should be able to state save non-Serializable Lists
> ------------------------------------------------------------
>
> Key: TRINIDAD-1236
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1236
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.0.9-core, 1.2.9-core
> 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.
> Reporter: Blake Sullivan
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
