Bugzilla – Full Text Bug Listing
| Summary: | Many to Many Override default Index out of bound error | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] Dali JPA Tools | Reporter: | Jolene Moffitt <jolene.moffitt> | ||||||
| Component: | General | Assignee: | Brian Vosburgh <brian.vosburgh> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | brian.vosburgh, karenfbutzke, neil.hauge | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 2.3 M1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jolene Moffitt
I see a problem even quicker, as soon as I click Override Default I end up with an index out of bounds error and 2 join-columns appears in the table. I am unsure of a solution, but I can reproduce it reliably with 2 breakpoints. Put one in GenericJavaJoinTable.updateSpecifiedJoinColumns(JoinTableAnnotation) and one in GenericJavaJoinTable.addSpecifiedJoinColumn(int) on the line right after this.specifiedJoinColumns.add(index, joinColumn). The problem is because the update that occurs after adding the resource join table might not happen until after that specifiedJoinColumn is added, then it gets removed in the update and the index out of bounds exception occurs. I can reproduce on a M-1 mapping by overriding the default join column and adding a second join column, and then deleting this newly added join column. This is in Java and using the Dali UI. Testing on wtp-R3.1RC2-20090526075706 - Create JPA project with EclipseLink 1.0 platform with oracle 11 database connection. - Create Address Entity with some attributes - Create Employee Entity with some attributes (ManagedEmployees which is a type – ValueHolderInterface) - Select managedemployees attribute from Employee entity and map as One to Many - Select Employee Entity for the Target Entity - Check the override default checkbox and click on the Edit button. - Receive the following error: org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IllegalStateException: missing counter: GenericJavaJoinColumn[012EF454] (EMPLOYEE_EMP_ID)) at org.eclipse.swt.SWT.error(SWT.java:3884) at org.eclipse.swt.SWT.error(SWT.java:3799) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(synchronizer.java:137) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) If I try to do anything else with One to Many mappings even for other attributes I continue to get errors: org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IllegalArgumentException: Index out of bounds) at org.eclipse.swt.SWT.error(SWT.java:3884) at org.eclipse.swt.SWT.error(SWT.java:3799) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench When this occurs I continue to get errors and have to re-start my project. I have reproduced these issues in 2.2, 2.1, and 2.0. Not that it makes it any less bad, but at least we know it's not a regression from previous releases. And Jolene is right, the project is hosed, try to select on another 1-m and you get listener not registered exception among others. A project clean doesn't do it because the panel itself is screwed up. The only workaround I see is opening a new window and closing out the old window, this makes the panels get rebuilt. Consider for 2.2.1 if appropriate. Created attachment 138978 [details]
candidate patch
Here's a first pass at a patch that is against the 2.2 maintenance branch, but, at the moment, can also be applied to HEAD. It *seems* to work.
Created attachment 139461 [details]
tweaked patch
Cleaned up the initial patch a bit and checked it into HEAD. Still not checked into maintenance stream.
Just to comment on the patch: This patch has the potential to fix a number of problems Dali has with the circular synchronization between its model and Java source code. The patch is code that will deactivate the Dali Java change listener whenever a Dali UI component that affects Java code has the focus (which, at the moment, is only the JPA Details View). In other words: When the JPA Details View has the focus, changes to the various JPA settings will modify the Dali model which in turn will modify the Java source code. Since the Dali Java change listener is deactivated at this point, none of the changes to the Java source code will be (unnecessarily) communicated back to the Dali model, reducing the chance for the Dali model and the Java source code to be out of synch (which happens easily since the Java change events occur asynchronously whenever their is a 0.5 second delay in changes to the Java source code). When the JPA Details View does NOT have the focus, the Dali Java change listener is active; so any changes to the Java source code will cause changes to the Dali model, which in turn will update the JPA Details View as necessary. The only obvious (possible) problem: If a background task directly modifies the Java source code in a way that is supposed to affect the Dali model (e.g. adding a @Basic annotation to an attribute) while the JPA Details View has the focus, the Dali model (and the JPA Details View) will be out of synch and there is a small chance that things will get a little out of wack. Nothing serious, but could be a nuisance. The hope is that any background task that wants to modify JPA annotations will do it via the Dali model and not by directly modifying the Java source code; in which case we won't have a problem. This fix appears to be working well in our lightly tested head stream. That said, there is some potential for a change in behavior with this patch that could cause problems in adopter code. Given that risk, and the fact that we haven't heard a lot about this problem in the field, I'm thinking we should leave this as a 3.0 fix only for now. Let me know if you have a different opinion. Marking as fixed in 3.0M1. |