hmm we already dont do anything with the exceptions there
so we only have to copy the list of request targets to detach before
iterating over it
or use a list that can handle that somehow

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

Reply via email to