The error can be reproduced by simply loading (or reloading) two or more file entry demos before navigating to the validation demo. I modified IDs so that they are different across all file entry demos and corrected the namespaces in the validation page, which were different, but the exception is still thrown. The mere presence of the ace:fileEntry components in those demos causes the problem, even when removing all their attributes so that they aren't bound to any bean property.

After configuring the showcase app as being in the development stage, the following exception can be seen. The stack trace doesn't show any ICEfaces classes.

Nov 26, 2015 1:39:00 PM org.icefaces.impl.application.ExtendedExceptionHandler handle
WARNING: queued exception
java.lang.ArrayIndexOutOfBoundsException: 3
at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:368)
at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:377)
at org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2579)
at org.apache.myfaces.application.ApplicationImpl.access$000(ApplicationImpl.java:129)
at org.apache.myfaces.application.ApplicationImpl$SystemListenerEntry.publish(ApplicationImpl.java:2784)
at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:610)
at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:625)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:84)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:200)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:399)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:317)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:204)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:311)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

It seems like the issue is related to something specifically in the fileentry demos in the showcase app.

Placing a file entry component in another demo only causes the exception when returning to the file entry demos.

Oddly enough, removing the id attribute from the forms in all file entry demos doesn't show the exception for a while, but it shows again after navigating 10-15 times among the file entry demos.

Copying and adding the file entry components as they are to another component's demos, one on each page, doesn't cause the exception even after navigating among such demos tens of times.

I've tried more things, and I came up with a way to avoid the exception from occurring. Th workaround consists simply in having all the demo contents inside the same form, instead of using two separate forms.

The Validation demo is the only ace:filEntry demo that uses two forms, one for configuration and one for the actual demo component. Using only one form prevents the error. Placing the ace:fileEntry component in the first form, instead of in the second one also prevents the error. This is not a general issue with having two forms on the same page, since the error only occurs when an ace:fileEntry component is not in the first form.

The bad news is that after applying the workaround (using only one form), the still demo fails: the validation message is not shown when the file to upload id larger than the maximum specified size, and the file uploads successfully instead of being prevented from uploading.

The validation problem in the comment above is actually fixed by simply updating the ace:message 'for' attribute to use the new form ID. However, because now the slider and the file entry component are in the same form, it's not possible to change the max file size using the slider, since the file entry always hijacks the request to do its own thing, and that's why it always require a separate form just for uploading.

I found a true workaround that allows the Validation demo to work normally. However, the placement of the components has to be different. This reveals some more clues about this issue.

First, I tried moving the ace:fileEntry component to the first form on the page (i.e. 'example-form'), and this caused no errors when navigating across the ace:fileEntry demos several times. Then, I thought that the ace:fileEntry component had to be in the first form on the page in order to avoid the error. So, I undid the previous change and just moved the 'upload-form' above the 'example-form' on the page, but this caused the same error when navigating to the demo. Then, keeping the 'upload-form' as the first form, I renamed it to 'example-form' (and updated the ace:message and ace:ajax tags to use this new id), and I renamed the original 'example-from' to something else (e.g. 'config-form'). In this case, there were no errors, and the demo worked as expected.

All the other ace:fileEntry demos have a single form and the ID is 'example-form' in all cases. So, it's interesting to see that the form where the ace:fileEntry component is in the Validation demo has to have the same ID as in the other demos. It also has to be the first form on the page, otherwise the same errors occur. If we use completely different form IDs in the Validation demo (i.e. no 'example-form'), then the errors occur again. Likewise, changing the form ID in another of the ace:fileEntry demos from 'example-form' to something else (e.g. 'test-form') also causes the error when visiting that demo for the second time.

So, it seems like when using MyFaces and a navigation style like the one used in the showcase, the form ID's have to be the same when they contain an ace:fileEntry component.

r46968: modified criteria for isListenerForSource() method in the inner class FileEntryFormSubmit.ReEnableCaptureSubmit to match that of the main class FileEntryFormSubmit, since both listeners are supposed to be applied only to forms that contain an ace:fileEntry component

Testing Notes: please run all regression tests.

Verified ICEfaces 4 trunk r46969. Tomcat 8, Myfaces/mojarra libs. Chrome 47, FF 43, IE 11, 10, 9, 8.

Verified Jenkins ICEfaces-4.1.1 Build#1 using MyFaces libs on Chrome48.