Home » Modeling » EMF » EMF editors keeps showing stale data and there's a danger of losing edits!
| EMF editors keeps showing stale data and there's a danger of losing edits! [message #639295] |
Mon, 15 November 2010 23:03  |
 Stefan Edlund
Messages: 127
Registered: July 2009
Location: IBM |
Senior Member |
|
|
Here's a somewhat basic question perhaps, but for some reason I can't get this working.
In my example I have an EMF class called Model. A model contains an EReference parameter to 0 or more NodeDecorators (another EMF class). A Model can also contain 0 or more other Models inside it.
Let's say a have create two models, M1 and M2 and that M2 is contained inside M1 (via the reference)
Next, I open two editors (the generated ModelEditor, a subclass of MultiPageEditorPart) first for M1, then another editor for M2. I change M2 by dragging a NodeDecorator into it (our user interface allows drag and drop) and then I save M2.
Now, when I go back to the M1 editor and expand it, the M2 model does NOT have the new NodeDecorator inside it. Worse, if I change M1 (by say dragging a NodeDecorator into it) and then save, it sometimes (but not always it seems) overwrite the M2 model and removes the new Node Decorator. So there's a real danger of losing edits here!!!
I've debugged, I can see that when I activate an editor it reloads any resources in its resource set that have changed. So I can't really figure out what's going on, it seems there's some subtle things that's beyond me.
Any advice is much appreciate.
Regards,
/ Stefan
|
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #639303 is a reply to message #639295] |
Tue, 16 November 2010 00:26  |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stefan,
Comments below.
Stefan Edlund wrote:
> Here's a somewhat basic question perhaps, but for some reason I can't
> get this working.
> In my example I have an EMF class called Model. A model contains an
> EReference parameter to 0 or more NodeDecorators (another EMF class).
> A Model can also contain 0 or more other Models inside it.
>
> Let's say a have create two models, M1 and M2 and that M2 is contained
> inside M1 (via the reference)
>
> Next, I open two editors (the generated ModelEditor, a subclass of
> MultiPageEditorPart) first for M1, then another editor for M2. I
> change M2 by dragging a NodeDecorator into it (our user interface
> allows drag and drop) and then I save M2.
So you have cross resource containment supported for this reference?
>
> Now, when I go back to the M1 editor and expand it, the M2 model does
> NOT have the new NodeDecorator inside it.
Are there two resources open in this editor?
> Worse, if I change M1 (by say dragging a NodeDecorator into it) and
> then save, it sometimes (but not always it seems) overwrite the M2
> model and removes the new Node Decorator.
It sounds like there are two resources...
> So there's a real danger of losing edits here!!!
>
> I've debugged, I can see that when I activate an editor it reloads any
> resources in its resource set that have changed.
Yes there is a resource delta processor that kicks in to unload and
reload resources that change in the workspace.
> So I can't really figure out what's going on, it seems there's some
> subtle things that's beyond me.
I'm not sure from just the description what's going wrong...
>
> Any advice is much appreciate.
>
> Regards,
> / Stefan
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #639308 is a reply to message #639303] |
Tue, 16 November 2010 01:09 |
Stefan Edlund
Messages: 127
Registered: July 2009
Location: IBM |
Senior Member |
|
|
Thanks Ed,
For both the "models" reference and the "nodeDecorators" reference in the Model EClass, I have the following:
Changeable: true
Container:false
Containment:false
Derived:false
Lower bound:0
Ordered: true
Resolve proxies:true
Transient:false
Unique:true
Unsettable: false;
Upper bound: -1
Volatile: false
Is that enough information?
Yes, there are two resources loaded in the M1 editor, it's a tree I can navigate. As far as I can tell the resource set in the EditingDomain contain the M1 and M2 models, and when I activate the M1 editor after changing M2, M2 is unloaded then reloaded. But the tree does not get updated to indicate this.
I probably need to do some more debugging to determine exactly why when I save M1 it overwrites M2. Not sure if this helps, but sometimes when I save M1, I get a confirmation dialog "The file {0} already exists. Do you want to replace the existing file?". It it only happens when I'm debugging, maybe there's some timing issue here...
Regards,
/ Stefan
|
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #639314 is a reply to message #639308] |
Tue, 16 November 2010 01:39 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stefan,
Comments below.
Stefan Edlund wrote:
> Thanks Ed,
>
> For both the "models" reference and the "nodeDecorators" reference in
> the Model EClass, I have the following:
>
> Changeable: true
> Container:false
> Containment:false
So they are non-containment references...
> Derived:false
> Lower bound:0
> Ordered: true
> Resolve proxies:true
> Transient:false
> Unique:true
> Unsettable: false;
> Upper bound: -1
> Volatile: false
>
> Is that enough information?
>
> Yes, there are two resources loaded in the M1 editor, it's a tree I
> can navigate. As far as I can tell the resource set in the
> EditingDomain contain the M1 and M2 models, and when I activate the M1
> editor after changing M2, M2 is unloaded then reloaded. But the tree
> does not get updated to indicate this.
I'd expect the tree to update based on the notifications that unloading
and reloading produce...
>
> I probably need to do some more debugging to determine exactly why
> when I save M1 it overwrites M2.
Certainly there is an attempt to save all the resources in the resource
set, although the options used are such that the old contents are
compared to the new contents and if they are the same, it's a no-op to save.
> Not sure if this helps, but sometimes when I save M1, I get a
> confirmation dialog "The file {0} already exists. Do you want to
> replace the existing file?".
That sounds more like a Save As thing...
> It it only happens when I'm debugging, maybe there's some timing issue
> here...
Hmmm. It sounds like there are cases where the M2 really isn't unloaded
and reloaded. I.e., it's not just that the tree doesn't show the
update, it really doesn't update and when you save, you save the old
version back. I don't know why that would happen though. I'd need to
be able to reproduce the problem myself...
>
> Regards,
> / Stefan
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | |
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #639796 is a reply to message #639792] |
Wed, 17 November 2010 20:16 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stefan,
Comments below.
Stefan Edlund wrote:
> Yes, this is what I see when I drag a new decorator into the M2
> editor. Right away, even before I save, there's a call to
> notifyChanged to the ModelItemProvider for the M2 model and the
> ChildrenStore for M2 is refreshed.
> Next, I save M2 and select the M1 editor. handleActivate() is called
> and it detects that M2 has changed in handleChangedResources(), so it
> reloads M2.
Well, the resource holding M2. M2 itself is turned into a proxy and all
adapters on it are cleared...
> However this is a different instance of M2 than above.
Yes, the old one is a proxy and there will be a new one to replace it.
> There is no notification after load to tell the M2 ModelItemProvider
> that it has been reloaded so that the ChildrenStore is refreshed.
No. All the adapters are cleared. Although that does produce a
notification....
>
> Or something to that effect... I might be way off here, this code is
> no easy to follow.
So the problem is more with the "parent" of M2, not M2 itself. It
really needs to resolve its proxy reference to the old M2 to reference
the new M2. A brute force solution would be to call
EcoreUtil.resolveAll after the reloading is complete. That should
cause the parent to resolve the proxy and maybe that notification will
be handled; maybe not, in which case it would be good for me to have a
self-contained test case (exported project) to reproduce the problem and
provide a fix...
>
> Thanks
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #647394 is a reply to message #639802] |
Wed, 05 January 2011 23:54 |
Stefan Edlund
Messages: 127
Registered: July 2009
Location: IBM |
Senior Member |
|
|
Hi Ed,
I'm finally back looking at this problem, sorry about the delay.
First, calling EcoreUtil.resolveAll() did not seem to help. I put the call in the last line of ModelEditor.doSave(...), like such:
EcoreUtil.resolveAll(editingDomain.getResourceSet());
Of course, this is only resolving resources in the resource set loaded by the current editor. Other editors resource sets are not changed.
We have a hook in our code where we get notified as soon as save is done in an editor. In there we put code to refresh the tree nodes in the project explorer, and that works great. I manually set resources in the project explorers resource set as modified when "contained" resources are changed.
In the same code, is there a way to get the resource sets for all open editors and do the resolveAll(...) call? Alternatively mark the resources as modified so they are reloaded?
I would be happy to try and provide you with a small self-contained project, but it would be nice to have some skeleton project to start with. Let me know if you have one.
Best Regards,
/ Stefan
|
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #647398 is a reply to message #647394] |
Thu, 06 January 2011 00:57 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stefan,
Comments below.
Stefan Edlund wrote:
> Hi Ed,
>
> I'm finally back looking at this problem, sorry about the delay.
Not a problem for me. :-P
>
>
> First, calling EcoreUtil.resolveAll() did not seem to help. I put the
> call in the last line of ModelEditor.doSave(...), like such:
>
> EcoreUtil.resolveAll(editingDomain.getResourceSet());
Is this really after reloading is complete?
>
> Of course, this is only resolving resources in the resource set loaded
> by the current editor. Other editors resource sets are not changed.
Of course they update based on listening to workspace deltas.
>
> We have a hook in our code where we get notified as soon as save is
> done in an editor. In there we put code to refresh the tree nodes in
> the project explorer, and that works great. I manually set resources
> in the project explorers resource set as modified when "contained"
> resources are changed.
>
> In the same code, is there a way to get the resource sets for all open
> editors and do the resolveAll(...) call? Alternatively mark the
> resources as modified so they are reloaded?
Generated EMF editors implement IEditingDomainProvider...
>
> I would be happy to try and provide you with a small self-contained
> project, but it would be nice to have some skeleton project to start
> with. Let me know if you have one.
I don't care if it's one project, just a zip file I can import into the
workspace and has everything needed to reproduce the example.
>
> Best Regards,
> / Stefan
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #647528 is a reply to message #647394] |
Thu, 06 January 2011 19:27 |
Stefan Edlund
Messages: 127
Registered: July 2009
Location: IBM |
Senior Member |
|
|
Hi Ed,
I created a stripped down version of STEM that you can import into your workspace. Here's the instructions.
Download the zip file at: http://www.eclipse.org/stem/ForEd.zip
Unzip into your workspace and import all the projects.
Start STEM by right-clicking on stem.product in org.eclipse.stem.ui, then Run As->Eclipse Application (if you see errors in the console, don't worry about it).
Close the welcome screen, then open the Designer perspective (click on the icon in the top left corner).
Create a new STEM project (also an icon in the top left, check the tooltip).
Now, to reproduce the problem I'm seeing.
1. Create a model M1 (Third icon from the top left in the toolbar).
2. Create a model M2
3. Create a model M3
4. Select the editor for M1
5. From the project explorer (open up the 'Models' folder in your project), drag M2 under M1, then Save
6. Select the editor for M2
7. Drag M3 under M2 and Save
8. Select the editor for M1. M3 is missing under M2.
The ecore file is in the org.eclipse.stem.core/model/model.ecore.
I really appreciate your help! I wouldn't be surprised if in the end it turns out there's something very basic wrong with our EMF models.
Regards,
/ Stefan
|
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #647540 is a reply to message #647528] |
Thu, 06 January 2011 22:48 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Stefan,
There are several issues. One comment I made earlier was "I would
expect calls to updateChildren from within notifiedChange of the
generated item providers to update the store" but unfortunately
Notification.RESOLVE is not handled the same way as Notification.SET.
Changing ItemProviderAdapter to do that helps a lot.
protected void updateChildren(Notification notification)
{
//.....
case Notification.RESOLVE:
case Notification.SET:
The other problem is that nothing prompts the proxies to resolve after a
reload. Adding
EcoreUtil.resolveAll(editingDomain.getResourceSet());
to handleChangedResources after all the changedResources are processed
in the for loop helps deal with that.
It all works much better with those two changes.
Please open a bugzilla for the first issue.
Stefan Edlund wrote:
> Hi Ed,
>
> I created a stripped down version of STEM that you can import into
> your workspace. Here's the instructions.
>
> Download the zip file at: http://www.eclipse.org/stem/ForEd.zip
>
> Unzip into your workspace and import all the projects.
>
> Start STEM by right-clicking on stem.product in org.eclipse.stem.ui,
> then Run As->Eclipse Application (if you see errors in the console,
> don't worry about it).
>
> Close the welcome screen, then open the Designer perspective (click on
> the icon in the top left corner).
>
> Create a new STEM project (also an icon in the top left, check the
> tooltip).
>
> Now, to reproduce the problem I'm seeing.
>
> 1. Create a model M1 (Third icon from the top left in the toolbar).
> 2. Create a model M2
> 3. Create a model M3
> 4. Select the editor for M1
> 5. From the project explorer (open up the 'Models' folder in your
> project), drag M2 under M1, then Save
> 6. Select the editor for M2
> 7. Drag M3 under M2 and Save
> 8. Select the editor for M1. M3 is missing under M2.
>
> The ecore file is in the org.eclipse.stem.core/model/model.ecore.
>
> I really appreciate your help! I wouldn't be surprised if in the end
> it turns out there's something very basic wrong with our EMF models.
>
> Regards,
> / Stefan
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | | |
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #721481 is a reply to message #639295] |
Thu, 01 September 2011 21:30 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Sorry for re-opening an old topic, but we're finally getting ready to move from 2.6 to 2.7 in STEM and are seeing an exception that I believe is caused by the fix to the problem discussed in this thread.
When changing our target platform from EMF 2.6.1 to 2.7.0, the editors that load STEM models w/proxies throw a NoSuchElementException (AbstractEList.java:717). But the root cause is shown 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.emf.edit.ui.provider.AdapterFactoryContentProvider.hasChildren(java.lang.Object) line: 198
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).isExpandable(java.lang.Object) line: 2127
org.eclipse.jface.viewers.TreeViewer.isExpandable(java.lang.Object) line: 588
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).isExpandable(org.eclipse.swt.widgets.Item, org.eclipse.jface.viewers.TreePath, java.lang.Object) line: 2153
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).updatePlus(org.eclipse.swt.widgets.Item, java.lang.Object) line: 2835
org.eclipse.jface.viewers.TreeViewer.updatePlus(org.eclipse.swt.widgets.Item, java.lang.Object) line: 852
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createTreeItem(org.eclipse.swt.widgets.Widget, java.lang.Object, int) line: 834
org.eclipse.jface.viewers.AbstractTreeViewer$1.run() line: 808
org.eclipse.swt.custom.BusyIndicator.showWhile(org.eclipse.swt.widgets.Display, java.lang.Runnable) line: 70
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createChildren(org.eclipse.swt.widgets.Widget, boolean) line: 782
org.eclipse.jface.viewers.TreeViewer.createChildren(org.eclipse.swt.widgets.Widget, boolean) line: 644
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createChildren(org.eclipse.swt.widgets.Widget) line: 753
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).internalInitializeTree(org.eclipse.swt.widgets.Control) line: 1533
org.eclipse.jface.viewers.TreeViewer.internalInitializeTree(org.eclipse.swt.widgets.Control) line: 833
org.eclipse.jface.viewers.AbstractTreeViewer$5.run() line: 1517
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.StructuredViewer).preservingSelection(java.lang.Runnable, boolean) line: 1443
org.eclipse.jface.viewers.TreeViewer.preservingSelection(java.lang.Runnable, boolean) line: 403
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.StructuredViewer).preservingSelection(java.lang.Runnable) line: 1404
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).inputChanged(java.lang.Object, java.lang.Object) line: 1510
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.ContentViewer).setInput(java.lang.Object) line: 280
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 bolded line above is how it applies to this thread. 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's causing this.
We're seeing this for code generated against 2.6.1 as well as after re-generating for 2.7.
Stefan and I are pretty stumped. Any suggestions?
Thanks,
-Matt
|
|
| |
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #721693 is a reply to message #721481] |
Fri, 02 September 2011 15:27 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Matthew,<br>
<br>
It looks like you're getting a resolve notification before the
children have been populated. You could override this method to
check for children in an optimized way (without resolving proxies).<small><br>
</small>
<blockquote><small> public boolean hasChildren(Object object)</small><br>
<small> {</small><br>
<small> return hasChildren(object, <b>true</b>);</small><br>
<small> }</small><br>
</blockquote>
Perhaps that will just move the problem to later when the children
are being populated though, but give it a try...<br>
<br>
<br>
On 01/09/2011 2:30 PM, Matthew Davis wrote:
<blockquote cite="mid:j3oss9$541$1@news.eclipse.org" type="cite">Hi
Ed,
<br>
<br>
Sorry for re-opening an old topic, but we're finally getting ready
to move from 2.6 to 2.7 in STEM and are seeing an exception that I
believe is caused by the fix to the problem discussed in this
thread. <br>
When changing our target platform from EMF 2.6.1 to 2.7.0, the
editors that load STEM models w/proxies throw a
NoSuchElementException (AbstractEList.java:717). But the root
cause is shown in this stack trace:
<br>
<br>
<br>
Daemon Thread [Thread-1] (Suspended (exception
org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException))
<br>
org.eclipse.emf.common.util.BasicEList<E>.get(int) line:
352 <br>
org.eclipse.emf.edit.provider.ItemProviderAdapter$ChildrenStore.get(org.eclipse.emf.ecore.EStructuralFeature,
int) line: 2217 <br>
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).updateChildren(org.eclipse.emf.common.notify.Notification)
line: 2577 <br>
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider.notifyChanged(org.eclipse.emf.common.notify.Notification)
line: 167 <br>
org.eclipse.stem.core.scenario.impl.ScenarioImpl(org.eclipse.emf.common.notify.impl.BasicNotifierImpl).eNotify(org.eclipse.emf.common.notify.Notification)
line: 380 <br>
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>(org.eclipse.emf.ecore.util.EcoreEList<E>).dispatchNotification(org.eclipse.emf.common.notify.Notification)
line: 255 <br>
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>(org.eclipse.emf.ecore.util.EcoreEList<E>).resolve(int,
org.eclipse.emf.ecore.EObject) line: 192 <br>
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>.resolve(int,
E) line: 66 <br>
org.eclipse.emf.ecore.util.EObjectResolvingEList<E>(org.eclipse.emf.common.util.BasicEList<E>).get(int)
line: 354 <br>
org.eclipse.emf.common.util.AbstractEList$EIterator<E1>.doNext()
line: 709 <br>
org.eclipse.emf.common.util.AbstractEList$EIterator<E1>.next()
line: 696 <br>
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).getChildren(java.lang.Object)
line: 366 <br>
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).hasChildren(java.lang.Object,
boolean) line: 423 <br>
org.eclipse.stem.core.scenario.provider.ScenarioItemProvider(org.eclipse.emf.edit.provider.ItemProviderAdapter).hasChildren(java.lang.Object)
line: 410 <br>
org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider.hasChildren(java.lang.Object)
line: 198 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).isExpandable(java.lang.Object)
line: 2127 <br>
org.eclipse.jface.viewers.TreeViewer.isExpandable(java.lang.Object)
line: 588 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).isExpandable(org.eclipse.swt.widgets.Item,
org.eclipse.jface.viewers.TreePath, java.lang.Object) line:
2153 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).updatePlus(org.eclipse.swt.widgets.Item,
java.lang.Object) line: 2835 <br>
org.eclipse.jface.viewers.TreeViewer.updatePlus(org.eclipse.swt.widgets.Item,
java.lang.Object) line: 852 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createTreeItem(org.eclipse.swt.widgets.Widget,
java.lang.Object, int) line: 834 <br>
org.eclipse.jface.viewers.AbstractTreeViewer$1.run() line:
808 <br>
org.eclipse.swt.custom.BusyIndicator.showWhile(org.eclipse.swt.widgets.Display,
java.lang.Runnable) line: 70 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createChildren(org.eclipse.swt.widgets.Widget,
boolean) line: 782 <br>
org.eclipse.jface.viewers.TreeViewer.createChildren(org.eclipse.swt.widgets.Widget,
boolean) line: 644 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createChildren(org.eclipse.swt.widgets.Widget)
line: 753 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).internalInitializeTree(org.eclipse.swt.widgets.Control)
line: 1533 <br>
org.eclipse.jface.viewers.TreeViewer.internalInitializeTree(org.eclipse.swt.widgets.Control)
line: 833 <br>
org.eclipse.jface.viewers.AbstractTreeViewer$5.run() line:
1517 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.StructuredViewer).preservingSelection(java.lang.Runnable,
boolean) line: 1443 <br>
org.eclipse.jface.viewers.TreeViewer.preservingSelection(java.lang.Runnable,
boolean) line: 403 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.StructuredViewer).preservingSelection(java.lang.Runnable)
line: 1404 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).inputChanged(java.lang.Object,
java.lang.Object) line: 1510 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.ContentViewer).setInput(java.lang.Object)
line: 280 <br>
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.StructuredViewer).setInput(java.lang.Object)
line: 1690 <br>
org.eclipse.stem.core.scenario.presentation.ScenarioEditor.createPages()
line: 943 <br>
org.eclipse.stem.core.scenario.presentation.ScenarioEditor(org.eclipse.ui.part.MultiPageEditorPart).createPartControl(org.eclipse.swt.widgets.Composite)
line: 348 <br>
...
<br>
<br>
The bolded line above is how it applies to this thread. 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's causing this.
<br>
<br>
We're seeing this for code generated against 2.6.1 as well as
after re-generating for 2.7.
<br>
<br>
Stefan and I are pretty stumped. Any suggestions?
<br>
<br>
Thanks,
<br>
-Matt
<br>
<br>
</blockquote>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #721722 is a reply to message #721693] |
Fri, 02 September 2011 16:49 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Thanks for the quick response. We tried overriding the hasChildren(...) method in a couple places. It seems to do what you expected, but still didn't quite work. The editor now opens OK in the default view (collapsed tree), but when you expand the tree and it tries to resolve the children, we get the same exception.
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: 172
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.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.jface.viewers.TreeViewer.createChildren(org.eclipse.swt.widgets.Widget, boolean) line: 644
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createChildren(org.eclipse.swt.widgets.Widget) line: 753
org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).handleTreeExpand(org.eclipse.swt.events.TreeEvent) line: 1485
org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(org.eclipse.swt.events.TreeEvent) line: 952
-Matt
[Updated on: Fri, 02 September 2011 16:49] Report message to a moderator |
|
|
| Re: EMF editors keeps showing stale data and there's a danger of losing edits! [message #721751 is a reply to message #721722] |
Fri, 02 September 2011 17:55 |
Ed Merks
Messages: 33216
Registered: July 2009 |
Senior Member |
|
|
Matt,
Yes, I'm not surprised. The notification handling code will really need
to be more careful that it might well get a resolve notification before
the child store is properly populated. We'll need a bugzilla for that.
On 02/09/2011 9:49 AM, Matthew Davis wrote:
> Hi Ed,
>
> Thanks for the quick response. We tried overriding the
> hasChildren(...) method in a couple places. It seems to do what you
> expected, but still didn't quite work. The editor now opens OK in the
> default view (collapsed tree), but when you expand the tree and it
> tries to resolve the children, we get the same exception.
>
> 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: 172
> 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.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.jface.viewers.TreeViewer.createChildren(org.eclipse.swt.widgets.Widget,
> boolean) line: 644
> org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).createChildren(org.eclipse.swt.widgets.Widget)
> line: 753
> org.eclipse.jface.viewers.TreeViewer(org.eclipse.jface.viewers.AbstractTreeViewer).handleTreeExpand(org.eclipse.swt.events.TreeEvent)
> line: 1485
> org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(org.eclipse.swt.events.TreeEvent)
> line: 952
>
> -Matt
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Fri Sep 20 03:37:44 GMT 2024
Powered by FUDForum. Page generated in 0.07364 seconds |
] 
Search
Help
Register
Login
Home
