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
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.