i think changing RequestCycle.detach to this: for (int i = 0; i < requestTargets.size(); i++)
instead of use an iterator there will kill the concurrent mod exception and also detach the new request target that is pushed to the top johan On Wed, Mar 19, 2008 at 11:39 PM, Maurice Marrink <[EMAIL PROTECTED]> wrote: > 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] > >
