[
https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086957#comment-13086957
]
Martin Grigorov commented on WICKET-3972:
-----------------------------------------
This is a hard one to track the bug...
There are two stable wicket:message components and the other are dynamically
generated depending on the request parameter value.
If I disable any of them then the app works, but otherwise the 'link' component
is not rendered, component use check runs, and for some reason during the
rendering of the error page the error message gets replaced by "wicket:message
with id '..' was already rendered".
> wicket:message attribute results in "The component was rendered already" error
> ------------------------------------------------------------------------------
>
> Key: WICKET-3972
> URL: https://issues.apache.org/jira/browse/WICKET-3972
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC5.1
> Environment: Linux Ubuntu, Tomcat 6, Java 6
> Reporter: Sergiy Barlabanov
> Attachments: quickstart.zip
>
>
> Seems like there is a problem with generation of tag and component IDs when
> using wicket:message as an attribute for tags inside ListView.
> The quickstart webapp is attached to this ticket. There are two pages in this
> webapp: HomePage with a ListView containing tags with wicket:message
> attribute and two tags with wicket:message attribute outside the ListView. If
> a user goes to the next page (SecondPage) using the link on HomePage and then
> goes back to HomePage using the link on SecondPage, the exception mentioned
> in the subject occurs.
> Seems that the ID generation for tags and components is wrong: the
> ComponentTag-s are cached together with the corresponding Markup and then
> reused for later renderings. But the problem is, that those ComponentTag-s
> are mutable (at least in case of tags with wicket:message attribute) and
> their IDs are changed on every rendering and this produces ID conflicts when
> MarkupContainer.renderNext tries to find or create components corresponding
> to the tags.
> Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In
> DEPLOYMENT mode everything seems to work. The solution would be to make
> ComponentTags immutable and do not allow to change them, but to create copies
> (there is mutable method in ComponentTag, which is used in some cases).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
