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. If required i can provide a small application (courtesy of Warren) that demonstrates the problem. So what do you guys think, shall i open up a jira issue for this? Maurice --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
