Issue 377: IndexOutOfBoundsException in ApplyRequestValuesPhase

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=377

I don't seem to be able to add comments to this issue, so I'm putting this here instead. Let me know if I'm being slow and could have commented on the issue.

We've also seen this bug using 1.1_01 on JBoss 3.2.6 and 3.2.8. We haven't tested 1.1_02 yet.

We see it on the live servers every now and then, and I've reproduced it a few times on a dev box by starting a long running query in one action method, then hitting the action link again before the query has completed.

If it helps, I could only reproduce it in IE -- Firefox didn't resubmit the form on the second click so the second request never hit the server.

[718 byte] By [guy.colemana] at [2007-10-3 1:59:45]
# 1
Guy,Thanks for the comments. In order to add comments, please request Observer access to the javaserverfaces project.I'll grant the request as soon as I see it.
rlubkea at 2007-7-14 18:58:27 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 2

I've been struggling with this same problem for some time (not in the same environment, though). It's been reported several times and commented on, usually by someone who wants a workaround rather than a fix. There's several workarounds.

To recreate in Firefox: submit a page with a long-running query, then click a link to another page, click a link to come back to the submitted page, then submit the page again.

What I did to workaround was set the id on every component. This was suggested by the vendor when I complained. Now that I've done this the error rarely occurs. Obviously, this is far from ideal. A non-obvious problem I ran into is that f:verbatim calls createUniqueId but doesn't allow you to set the id. Luckily it's easy create a component that works the same as f:verbatim but allows you to set the id. To make sure I'd set the id on every component I extended UIViewRoot, overriding createUniqueId to print out a message.

Another workaround I tried was extending UIViewRoot and synchronizing its methods.

Another one I've seen mentioned is to use JavaScript to disable the form.

I've been thinking of another workaround where I'd implement my own Lifecycle and synchonize on the UIViewRoot for the length of the lifecycle.

I think that multiple submits of a form will cause problems if JSF doesn't ignore subsequent submits for the same request. Maybe JSF could put a requestId on each form and ignore any but the first one received. Application developers shouldn't have to handle this.

BrantKnudsona at 2007-7-14 18:58:27 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 3
What container are you all using?
rlubkea at 2007-7-14 18:58:27 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 4
Aside from JBoss (I got that one)
rlubkea at 2007-7-14 18:58:27 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 5

I've given this a bit more thought, and I'm guessing you're both using serverside state saving.

If this is in fact the case, please upgrade to 1.1_02 [1]. This had changes to server side

state managed that should correct this.

[1] https://javaserverfaces.dev.java.net/files/documents/1866/33714/jsf-1_1_02.zip

rlubkea at 2007-7-14 18:58:27 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...