My current patch involved this:
for (int i = 0; i < requestTargets.size(); i++)
{
IRequestTarget target =
(IRequestTarget)requestTargets.get(i);
if (target != null)
{
try
{
target.detach(this);
}
catch (RuntimeException e)
{
log.error("there was an error cleaning
up target " + target + ".", e);
}
}
}
But if you copy the requestTragets before you are going to detach them
and then iterate over them that would work too i guess.
Only question is, what is more expensive copying a list/stack only a
few items big or needlessly detaching 1 or 2 RequestTargets which
should still be detached anyway.
Maurice
On Thu, Mar 20, 2008 at 12:13 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> 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]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
