[
https://issues.apache.org/jira/browse/MYFACES-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15151965#comment-15151965
]
Christian Beikov commented on MYFACES-4028:
-------------------------------------------
Well the id attribute is not the same as an id attribute of a normal component
since "test:row" is a custom tag in a taglib.
The id attribute is just used for a div, which is evaluated at view render time.
The problem is when doing #{not empty id} which causes the "id" and by that the
"cc.clientId" to be accessed and cached.
It would be nice if the JSTL tags had some kind of blacklist of properties that
may not be used along with them. That way an exception could be thrown because
using "clientId" during view build time is always illegal.
> 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
> Assignee: Leonardo Uribe
> 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)
