As requested by Johan i created a jira issue
https://issues.apache.org/jira/browse/WICKET-1438 and attached an
application showing the original problem.
Maurice
On Thu, Mar 20, 2008 at 12:22 AM, Maurice Marrink <[EMAIL PROTECTED]> wrote:
> 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]
