Bug 333711

Comment 1 Ed Merks 2011-01-06 19:11:21 EST

The fix is committed to CVS for 2.7.

Comment 2 Ed Merks 2011-05-10 11:57:53 EDT

The changes are available in EMF 2.7 M7 or an earlier build.

Comment 3 Matthew Davis 2011-09-02 15:24:33 EDT

Adding to existing bug, as this is related to the initial fix.  If you'd prefer it opened in a new bug, please let me know.  Thanks.

---

After switching from EMF 2.6 to EMF 2.7, when opening an editor on a model with unresolved proxies, a NoSuchElementException  (AbstractEList.java:717) is thrown and caught by the UI.  The root cause, however, is an IndexOutOfBoundsException as seen in this stack trace:

Daemon Thread [Thread-1] (Suspended (exception org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException))	
org.eclipse.emf.common.util.BasicEList<E>.get(int) line: 352	
org.eclipse.emf.edit.provider.ItemProviderAdapter$ChildrenStore.get(org.eclipse.emf.ecore.EStructuralFeature, int) line: 2217	
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).updateChildren(org.eclipse.emf.common.notify.Notification) line: 2577	
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider.notifyChanged(org.eclipse.emf.common.notify.Notification) line: 167	
org.eclipse.stem.core.scenario.impl.ScenarioImpl(org.eclipse.emf.common.notify.impl.BasicNotifierImpl).eNotify(org.eclipse.emf.common.notify.Notification) line: 380	
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>(org.eclipse.emf.ecore.util.EcoreEList<E>).dispatchNotification(org.eclipse.emf.common.notify.Notification) line: 255	
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>(org.eclipse.emf.ecore.util.EcoreEList<E>).resolve(int, org.eclipse.emf.ecore.EObject) line: 192	
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>.resolve(int, E) line: 66	
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>(org.eclipse.emf.common.util.BasicEList<E>).get(int) line: 354	
org.eclipse.emf.common.util.AbstractEList$EIterator<E1>.doNext() line: 709	
org.eclipse.emf.common.util.AbstractEList$EIterator<E1>.next() line: 696	
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).getChildren(java.lang.Object) line: 366	
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).hasChildren(java.lang.Object, boolean) line: 423	
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).hasChildren(java.lang.Object) line: 410	
...
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.StructuredViewer).setInput(java.lang.Object) line: 1690	
org.eclipse.stem.core.scenario.presentation.ScenarioEditor.createPages() line: 943	
org.eclipse.stem.core.scenario.presentation.ScenarioEditor(org.eclipse.ui.part.MultiPageEditorPart).createPartControl(org.eclipse.swt.widgets.Composite) line: 348	
...


The addition of Notification.RESOLVE falling into Notification.SET to the switch in ItemProviderAdapter.updateChildren(...) is the difference between EMF 2.6.x and 2.7.0 that appears to be causing this.

Comment 4 Stefan Edlund 2012-01-17 18:35:37 EST

Remove dependency on STEM bug 329503 since we now have a fix for the danger of losing edits. However, we are still blocked from moving to EMF 2.7 in STEM due to the exception reported by Matt below.

Comment 5 Ed Merks 2012-01-18 07:12:29 EST

I created a test case to reproduce the problem and then fixed it by guarding RESOLVE to avoid updating in the case where there is no child to update at the notification index.

I've committed fixes to git for 2.8 and 2.7.2.

Comment 6 Ed Merks 2012-03-31 14:24:14 EDT

The changes are available in the M6 build.