Eclipse Community Forums: GMF (Graphical Modeling Framework) » Shared Editing Domain

Help

Home

Home » Modeling » GMF (Graphical Modeling Framework) » Shared Editing Domain - Errors after saving diagram changes

Show: Today's Messages :: Show Polls :: Message Navigator

Shared Editing Domain - Errors after saving diagram changes [message #742737]

Thu, 20 October 2011 19:34

Nigel Daniels

Messages: 66
Registered: July 2009

Member

Hi all,

I followed this article to create a project with two diagrams that use a
shared editing domain and model:

http://wiki.eclipse.org/Graphical_Modeling_Framework/Tips#Sharing_single_EditingDomain_instance_across_several_diagrams

This seems to work in that I can make changes in either diagram (both
become marked as dirty). I can reference new items from one to another.
Overall it seems to work. However when I save it is as though the
transactional editing becomes 'detached' from the diagram.

For example:
I open super Diagram A
then sub Diagram B
move a node on Diagram B (both marked dirty)
hit Ctrl-S to save

Now I try and move a node on Diagram B but it 'snaps back', I cannot
move it (no stack trace but it's clearly broken). If I try and open a
context menu on the diagram I get a stack trace (see below) and only the
global parts of a contexct menu.

Attempting different things and sequences can result in different
symptoms but all seemingly driven by the same cause. It seems that when
a call is made to get the transactional editing domain using the static
call to:

TransactionUtil.getEditingDomain(EObject eObject)

(or similar) it turns out that the DiagramImpl passed has a null
Resource or ResourceSet, depending on what I tried to do.

The problem is that I have no idea where the Resource or ResouceSet is
going missing? It looks like it was there before I saved. Any help or
advice on what could be going on will be very welcome.

Thanks, Nigel

Stack trace :

!ENTRY net.london3d.gmf.diagramB 4 0 2011-10-20 20:23:04.218
!MESSAGE Error building context menu
!STACK 0
java.lang.NullPointerException
at
testmodel.diagramB.part.DiagramEditorContextMenuProvider.buildContextMenu(DiagramEditorContextMenuProvider.java:58)
at
org.eclipse.gef.ContextMenuProvider.menuAboutToShow(ContextMenuProvider.java:63)
at
org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:338)
at
org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:469)
at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:465)
at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:491)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:241)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3783)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1398)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1379)
at org.eclipse.swt.widgets.Menu.menuWillOpen(Menu.java:689)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5037)
at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
at org.eclipse.swt.internal.cocoa.NSMenu.popUpContextMenu(NSMenu.java:68)
at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:235)
at org.eclipse.swt.widgets.Display.runPopups(Display.java:3706)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3277)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
at org.eclipse.equinox.launcher.Main.main(Main.java:1384)

Report message to a moderator

Re: Shared Editing Domain - Errors after saving diagram changes [message #743256 is a reply to message #742737]

Fri, 21 October 2011 09:17

Nigel Daniels

Messages: 66
Registered: July 2009

Member

Hi,

in case it helps I have attached the projects mentioned in my first
post. This was created using Eclipse Helios SR2.

If you run the project open diagram A, to open diagram B use the option
on the Diagram A context menu titled 'Open TypeB Diagram'. Nodes added
to Diagram A should be able to see nodes on Diagram B as part of their
properties... until things break :(

Thanks for any help.

Nigel

On 20/10/2011 20:34, Nigel Daniels wrote:
> Hi all,
>
> I followed this article to create a project with two diagrams that use a
> shared editing domain and model:
>
> http://wiki.eclipse.org/Graphical_Modeling_Framework/Tips#Sharing_single_EditingDomain_instance_across_several_diagrams
>
>
> This seems to work in that I can make changes in either diagram (both
> become marked as dirty). I can reference new items from one to another.
> Overall it seems to work. However when I save it is as though the
> transactional editing becomes 'detached' from the diagram.
>
> For example:
> I open super Diagram A
> then sub Diagram B
> move a node on Diagram B (both marked dirty)
> hit Ctrl-S to save
>
> Now I try and move a node on Diagram B but it 'snaps back', I cannot
> move it (no stack trace but it's clearly broken). If I try and open a
> context menu on the diagram I get a stack trace (see below) and only the
> global parts of a contexct menu.
>
> Attempting different things and sequences can result in different
> symptoms but all seemingly driven by the same cause. It seems that when
> a call is made to get the transactional editing domain using the static
> call to:
>
> TransactionUtil.getEditingDomain(EObject eObject)
>
> (or similar) it turns out that the DiagramImpl passed has a null
> Resource or ResourceSet, depending on what I tried to do.
>
> The problem is that I have no idea where the Resource or ResouceSet is
> going missing? It looks like it was there before I saved. Any help or
> advice on what could be going on will be very welcome.
>
> Thanks, Nigel
>
>
>
> Stack trace :
>
>
>
> !ENTRY net.london3d.gmf.diagramB 4 0 2011-10-20 20:23:04.218
> !MESSAGE Error building context menu
> !STACK 0
> java.lang.NullPointerException
> at
> testmodel.diagramB.part.DiagramEditorContextMenuProvider.buildContextMenu(DiagramEditorContextMenuProvider.java:58)
>
> at
> org.eclipse.gef.ContextMenuProvider.menuAboutToShow(ContextMenuProvider.java:63)
>
> at
> org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:338)
> at
> org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:469)
>
> at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:465)
> at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:491)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:241)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
> at org.eclipse.swt.widgets.Display.sendEvent(Display.java:3783)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1375)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1398)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1379)
> at org.eclipse.swt.widgets.Menu.menuWillOpen(Menu.java:689)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:5037)
> at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method)
> at org.eclipse.swt.internal.cocoa.NSMenu.popUpContextMenu(NSMenu.java:68)
> at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:235)
> at org.eclipse.swt.widgets.Display.runPopups(Display.java:3706)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3277)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
> at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
>
>
>
>

Attachment: TestProject.zip
(Size: 636.18KB, Downloaded 370 times)

Report message to a moderator

Re: Shared Editing Domain - Errors after saving diagram changes [message #815307 is a reply to message #743256]

Wed, 07 March 2012 13:45

Martin P. Minguell

Messages: 4
Registered: March 2012

Junior Member

Hi Nigel,

I'm having the same problem in a project I'm working on.
Did you solve this issue at the end or did you take a different approach?

Any extra information regarding this issue is welcome.

Thanks.
Martin

Report message to a moderator

Re: Shared Editing Domain - Errors after saving diagram changes [message #815943 is a reply to message #815307]

Thu, 08 March 2012 08:32

Andreas Muelder

Messages: 73
Registered: July 2011

Member

Hi Martin,

I think that the resources are unloaded after saving the diagram. Thus, the eResource of the Diagram is null. You have to eliminate all calls to resourceinfo.dispose or editingdomain.dispose.

I implemented a working editor with a shared EditingDomain successfully with help of the project GMFTools,
you should give it a try:

http://code.google.com/p/gmftools/wiki/SharedEditingDomain

Regards,
Andreas

Report message to a moderator

Re: Shared Editing Domain - Errors after saving diagram changes [message #870658 is a reply to message #815943]

Wed, 09 May 2012 09:09

mohamed ahmed

Messages: 4
Registered: May 2012

Junior Member

hi Andreas,

i try to use a shared EditingDomain for tree different editors GMF using the first link (Not the way using GMFTools). it seems that it works but i don't see this modofication after running i.e i want to access to the shared EditingDomain to see how it works during running and when i'm creating a new diagram.

Hope that you understand my problem,
Best regards ,

Report message to a moderator

Re: Shared Editing Domain - Errors after saving diagram changes [message #884637 is a reply to message #870658]

Mon, 11 June 2012 14:33

Ondra Netocny

Messages: 12
Registered: July 2011

Junior Member

Hi, everybody!
I am working on very similar project as you, and I have got the same problem, that Nigel mentioned. Have somebody resolved this problem with snapped diagram nodes? I would be grateful, for any kind of help.

Ondra

Report message to a moderator

Re: Shared Editing Domain - Errors after saving diagram changes [message #907322 is a reply to message #884637]

Mon, 03 September 2012 19:00

Arto Jarvinen

Messages: 32
Registered: May 2010
Location: Sweden

Member

I'm having the same issue. This is what I've found so far: the save causes a call to ???DocumentProvider.handleElementChanged(). This method unloads the resources for diagram A and loads the resources for diagram B leaving diagram A "empty". When a call is then made to DiagramEditorContextMenuProvider.buildContextMenu, the call TransactionUtil.getEditingDomain() gives null since it is passed a proxy instead of a loaded element (I'm quite new here so I might not get the vocabulary right but the method names should be correct at least). The result is a strack trace. I believe the same problem causes the icons to get stuck.

The symptom goes away (at least for the few cases I've tested) if I prevent the unloading of resources by commenting out changedResource.unload() in handleElementChanged() but I wouldn't bet on this as a permanent solution Smile

My guess is that the common editing domain requires a different strategy for handling changes. That's where I'm now. Pls let me know what you've found out in the mean time.

-A

Blog: http://www.ostrogothia.com/process/

[Updated on: Mon, 03 September 2012 19:23]

Report message to a moderator

Previous Topic:	Multiple notation elements referencing the same domain element
Next Topic:	MouseMotionListener and Link Creation

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 23:10:53 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter