In Trinidad framework, we have a customization / changeManager feature, one of the subfeatures there is to be able to reorder child components of the same parent. The usecase is a very common Design-time at Run-time feature where the components are reordered inside same container parent by Drag-And-Drop in a canvas. This feature is broken when we are trying to update to Mojarra 2.1.8, so this is a regression from Mojarra 2.1.7 for which we are requesting a fix a.s.a.p.
I have tried to scale down this feature in a simple managed bean code and attached the testcase. All I'm doing in the managed bean is re-ordering children, and expecting that 1. if the component tree state is restored by RI, the new order is restored, or 2. if the jsf page is re-read and tags re-executed, then RI should re-instate the children is in its original index.
To test it, run the 'Trinidad_testpage.jsf' page provided as testcase (note the components are from Trinidad, so you will need to include Trinidad library, you can yourself emulate the behavior in any other component library you wish, since the essense of defect is showcased). In the page, click on the button, this is expected to reorder the two outputText children (you will see this happen fine in 2.1.7). In 2.1.8, instead, the following exception is encountered and the reorder fails.
It seems that RI is calling on the List implementation to add a child at a index greater than zero, at a point when there were no children at all.
1. The issue happens only for facelets case, not JSP.
2. The issue happens when partial state saving is enabled or disabled.
About the attached testcase:
1. application73.zip is a JDeveloper workspace, if you have JDev installed, it is convenient for you to just run it.
2. If you do not have JDev, then you can extract out / study the code in 'ChangeBeanOne.java' , 'DebugPhaseListener.java', 'Trinidad_testpage.jsf' and it should be easy for you to do the same using any component library / IDE.
3. It is assumed that you would run it first in 2.1.7 to see all is well, and then you can instead use the 2.1.8 jar provided in the zip file to see the issue (in JDev it is easy, you remove the included JSF 2.1 library, and add the included jars as the top entry in class path for the test app)