[
https://issues.apache.org/jira/browse/WICKET-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Compagner reassigned WICKET-1438:
---------------------------------------
Assignee: Johan Compagner
yeah we need to check out why the header component is not found
(besides fixing the loop that is not that big of a deal)
because it seems that the detach behavior of webpage never finds the header
component because it is inserted with an index.
Maybe that is also why the test didn't work? (the disabled part of that body
check)
> detach behavior
> ---------------
>
> Key: WICKET-1438
> URL: https://issues.apache.org/jira/browse/WICKET-1438
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.1
> Reporter: Maurice Marrink
> Assignee: Johan Compagner
> Attachments: securebutton_app.rar
>
>
> This was originally posted as a ConcurrentModificationException during detach
> on the wicket user list (http://markmail.org/message/xnrot5hm4wvow7dq) but
> later investigations show that there is something else not right.
> Let me begin by restating the original problem:
> A couple of days ago Warren came to me with a problem. If he attached
> a behavior to a component which potentially throws a
> RestartResponseAtInterceptPageException a
> ConcurrentModificationException would bubble all the way into tomcat
> code.
> Now you probably are going to say: "Then don't do that" ;) but the
> fact that an exception escapes wicket is imo reason to investigate.
> So i did some digging. The situation is as follows:
> In the renderHead method of an IHeaderContributor a check is performed
> for an authenticated user, if none is found a RRAIPE is thrown.
> One of the places that executes renderHead is the onDetach of WebPage.
> Now suppose we have a Page A which has a component decorated with this
> header contributor, the page also contains a Button to log off users.
> The onsubmit for this button is as simple as log user off and
> setResponsePage(class).
> This page is usually only accessible if an authenticated user is
> available so everything works fine if that is the case.
> But then the user decides to log off, the onsubmit is triggered and
> exits normally. the request continues and reaches the point where the
> RequestCycle is detaching all RequestTargets (at that point there are
> 2 targets, 1 for the current page and 1 set during the onsubmit).
> During the detach the renderHead method is executed along with the
> check for an authenticated user. Since there isn't one anymore a
> RRAIPE is thrown, adding a 3rd target to the stack of RequestTargets.
> The RRAIPE bubbles up to RequestCycle.detach() and is caught and
> logged there. Then wicket attempts to detach the next RequestTarget
> but since an iterator is used to loop through all targets, the
> iterator detects the stack has been changed and throws a
> ConcurrentModificationException. Ultimately resulting in a tomcat
> error page.
> I tried changing the iterator loop to a regular for(int i=0;i < .....)
> loop and this seems to fix the problem, even if later on more
> requesttargets are added wicket happily executes them and comes up
> with the desire page.
> There is one disadvantage i see with this solution: the requesttarget
> throwing the RRAIPE is not fully detached. Perhaps the RRAIPE can be
> swallowed after it has added a RequestTarget and only in the case of a
> detach phase. That way the rest of the page could be normally
> detached.
> Here is where it gets interesting:
> Johan noticed that WebPage.detach should not call renderHead during detach.
> In fact the only reason it does so is during development when it does not
> detect a header element. It then checks if there indeed should not be a
> header by visiting the behaviors and comparing the output to what it
> currently has. However as the code comments point out it then does nothing
> with that information because the code that should handle it does not work
> yet.
> So the question became why does the page does not have a header element. At
> first i thought this is because in this case a setResponsePage is done which
> would suppress any rendering of the current page.
> However this is not the case as renderhead is also called during detach in a
> normal page render. It does not matter if the markupfile contains a header
> element or not. As it turns out the presence of a header element is checked
> by getting a wicket component with id _header_ This always returns null as
> there is no such child component. There is however a child component with an
> id like _header_0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
