[
https://issues.apache.org/jira/browse/MYFACES-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147900#comment-15147900
]
Leonardo Uribe commented on MYFACES-4028:
-----------------------------------------
There is not any bug here.
A Converter or a Validator is an object that can be attached to a component,
and this object will be saved and restored with the component tree. If the
object does not implements Serializable interface, the values inside
selectItems are discarded by the state saving algorithm. According to the
algorithm used, the behavior is different, because since the start if the
Converter does not implement Serializable, StateHolder or PartialStateHolder,
the state stored in the converter will be lost.
If it works in Mojarra it is just by luck, because it shouldn't. I'll close
this issue as invalid. Thanks for provide the example, it helps to solve the
issue.
> Custom Taglib with composite components and JSTL
> ------------------------------------------------
>
> Key: MYFACES-4028
> URL: https://issues.apache.org/jira/browse/MYFACES-4028
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.1.17, 2.2.9
> Reporter: Christian Beikov
> Attachments: issue.zip
>
>
> I tested this on Wildfly 10.0.0.CR5 with both, MyFaces 2.1.17 and 2.2.9 but I
> suppose this issue is not specific to my environment.
> The example project can be found on Github:
> https://github.com/beikov/myfaces-composite-jstl-issue
> I think the essential problem is, that a composite component passes an EL
> expression to a custom tag which then uses the expression in a JSTL Tag.
> I don't know if it's just illegal to do something like this, or if there is
> an actual bug, but if it is the former, I'd expect an exception.
> Depending on whether the property
> "org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE" is enabled
> the behavior is different.
> When enabled, the converter that is attached to the composite component will
> be considered for state saving which in this case leads to a converter
> without state when restoring and finally leading to a converter exception on
> postback.
> When disabled, the first postback request just seems to do nothing, but then,
> it seemingly works as expected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
