Community
Participate
Working Groups
Build Identifier: We have a class Order that has an ordered list of OrderShipments mapped with the following JPA annotations: @PrivateOwned @OneToMany(mappedBy="order", cascade=CascadeType.ALL) @OrderBy(value="index") We hit a case where when attempting to merge an Order that has 2 OrderShipments an ArrayIndexOutOfBoundsException is thrown from the Vector class when attempting to remove the value from the original list at line 542 of CollectionChangeRecord. The problem doesn't happen every time and it seems to depend on whether or not we merge other objects in the session before merging the Order. I was able to determine that the problem stems from what appears to be extra OrderedChangeObjects. I'm going to attach a file that shows the OrderedChangeObjects that are created in the failure case. The "extra" OrderedChangeObjects cause the code to attempt to remove the same more objects from the original list than exist in the list. I noticed that in the case where it works the AttributeChangeListener with owner = Order has ignoreEvents = true but in the case where it fails the ignoreEvents = false which causes the extra OrderedChangeObjects. Reproducible: Always
Created attachment 162523 [details] Stack trace of the exception thrown
Created attachment 162524 [details] Stack trace of OrderChangeObject creations
Is it possible to provide a recreatable test case?
Unfortunately I can't just submit a test case with our full data model. For now we removed the @OrderBy annotation to avoid the problem. I can pretty easily reproduce the issue locally if there's anything that I can debug that would provide more insight. When I get some free time I can try and extend some of your existing test models to recreate something closer to the structure that we have to see if I can create a test case.
you may be able to work around by setting the persistence unit property: eclipselink.weaving.changetracking to false
That reminds me, one thing I forgot to mention previously is that we're using static weaving, I'm not sure if that changes the behavior at all. We didn't actually need the ordering though so it was easy enough to just remove the ordering.
Static weaving and Dynamic weaving produce the same result - just at different stages in the application lifecycle.
Setting target and priority. See the following page for details of the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
