[
https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087147#comment-13087147
]
Peter Ertl commented on WICKET-3972:
------------------------------------
Short summary on what I found so far:
The problem lies within WicketMessageTagHandler, WicketMessageResolver and the
behavior of Page.getAutoIndex().
When rendering HomePage for the 1st time WicketMessageResolver resolves the
'wicket:message' attributes and sets the component id of the affected
components to '_message_attr_'.
WicketMessageTagHandler will detect all component with '_message_attr_' and add
an auto index. The auto index starts with zero when rendering begins and
returns unique id's for dynamically creating unique component ids.
So after the first render we have the first input tag resolved with id =
'_message_attr_4' (the one that causes the crash later). Now we redirect to
SecondPage and return. Since the list view will create another tag with
'wicket:message' it will receive ''_message_attr' as temporary component id.
Again WicketMessageTagHandler tries to assign an auto index (which starts with
zero every new render). In this example it gets index = 4 by chance (unlucky!)
which already exists so we get a duplicate component id.
The solution is probably to check if a component already exists when creating
new component id's with auto index or to keep auto index incrementing over
different page id's for the same page (however this will make stateless pages
stateful).
I keep on investigating...
> 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
