[
https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087197#comment-13087197
]
Juergen Donnerstag commented on WICKET-3972:
--------------------------------------------
I don't think your observations are completely right. *Handlers are executed
while loading the markup and before the markup gets cached. They get re-used
for multiple instances of typically (but necessarily) the same Components. The
Page instance is not known. The main purpose of *Handlers are to identify tags
which Wicket's render process must somehow handle.
*Resolvers are used during the render process to automatically create (or
find/resolve) components which know how to handle the tag. Many *Resolvers
create auto-components, which are typically transparent, and which are
automatically removed again after the render process. They get re-created with
the next render cycle. The Page is known during the render process. And because
the page auto-index gets incremented, it should never happen that for the same
page instance components with the same id are created. I don't think we need
some other mechanism. A *Resolver should never change the tag id, only the
*Handler may.
The solution is much simpler. WicketMessageTagHandler.resolver() should not
call tag.setId()
> 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
> Assignee: Peter Ertl
> Attachments: auto-index-inside-markup.patch, 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
