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 < re
My current patch involved this:
for (int i = 0; i < requestTargets.size(); i++)
{
IRequestTarget target =
(IRequestTarget)requestTargets.get(i);
if (target != null)
{
try
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
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 ca
hmm this is only in development..
i guess we just need to swallow all exceptions there. it doesn't make
anysense to have restart exceptions in the detach
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. I
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" ;)
