Eclipse Community Forums: GMF (Graphical Modeling Framework) » Exception on delete from fully synchronised diagram

Help

Home

Home » Modeling » GMF (Graphical Modeling Framework) » Exception on delete from fully synchronised diagram

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

Exception on delete from fully synchronised diagram [message #131760]

Fri, 01 June 2007 08:58

Eclipse User

Originally posted by: james.willans.xactium.com

We are hitting a strange bug with deleting a view element (node) using
"delete from model", the bug occurs when the same semantic element is also
viewed in another diagram (via CanonicalEditPolicy). The bug manifests
itself as the following Java exception:

java.lang.NullPointerException
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSettingDelegate (BasicEObjectImpl.java:1526)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1019)
at BS.impl.BS_ModelImpl.eGet(BS_ModelImpl.java:115)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1002)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:994)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:989)
at
BS.diagram.providers.BSStructuralFeatureParser.getStringByPa ttern(BSStructuralFeatureParser.java:81)
at
BS.diagram.providers.BSStructuralFeatureParser.getStringByPa ttern(BSStructuralFeatureParser.java:73)
at
BS.diagram.providers.BSAbstractParser.getPrintString(BSAbstr actParser.java:110)
at
BS.diagram.edit.parts.AssessmentAssessment_kindEditPart.getL abelText(AKEditPart.java:208)

at
BS.diagram.edit.parts.AssessmentAssessment_kindEditPart.refr eshLabel(AKEditPart.java:417)

I am presuming that the second diagram isn't aware that a delete is
occuring, and is therefore refreshing its label as a result of a model
change. The exception is thrown because eGet is supplied with a
StructuralFeature from a class other than that of the the object's it is
being called upon. At the other end of the exception "getLabelText" is
called on an editPart which comes about from a LabelMapping on a
NodeMapping in the GMF map model. It is that NodeMapping which is the
target of the "delete from model" in the generated implementation.

What seems to be happening is that resolveSemanticElement in the labels
editPart calls getElement() on its view. Rather than returning the
correct semantic element (of whose class the structural feature belongs),
ViewImpl::getElement() starts to ascend through the container hierarchy
because !isSetElement() returns true and produces the model element
underlying the top level diagram. The setting of the state associated
with isSetElement seems to happen earlier on in the delete process.

Can anyone shed any light on what might be going on here, and how best to
resolve it? I don't understand the usage of isSetElement (and its
associated state)? My best guess is that it is an ordering issue, but I
would appreciate some help figuring out how to fix it.

Thanks,

James

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #131785 is a reply to message #131760]

Fri, 01 June 2007 12:17

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello James,

Are you using the same EditingDomain instance fr both diagrams?..

Concerning the situation you are having: please submitt a request with the
full stack trace inside and clear description of your situation and I'll
be able to fix it. Most important information is: do you have two opened
diagrams working upon the same model file in the same Editing domain or in
different?

-----------------
Alex Shatalin

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #131792 is a reply to message #131785]

Fri, 01 June 2007 12:28

Eclipse User

Originally posted by: james.willans.xactium.com

Alex,

We have two open diagrams on the *same* editing domain.

Does that help?

James

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #131796 is a reply to message #131792]

Fri, 01 June 2007 13:19

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello James,

Sure. Then the responsibility of GMF will be to generate label EditPart working
in this situation without exception.

In the same time you should adopt generated code to remove additional views
from the second diagram on deleting domain element. You can see generated
???BaseItemSemanticEditPolicy.addDestroyShortcutsCommand() as an example
- this method was recently added into the generator to automatically remove
all the shortcuts on removing domain model element.

-----------------
Alex Shatalin

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #131799 is a reply to message #131796]

Fri, 01 June 2007 14:12

Eclipse User

Originally posted by: james.willans.xactium.com

Hi Alex,

Thanks for the advise - it is much appreciated. I cannot find
???BaseItemSemanticEditPolicy.addDestroyShortcutsCommand() in our
generated code, we are using 3.3 M6. I'm not sure what you are
recommending we do based on this code?

James

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #131808 is a reply to message #131799]

Fri, 01 June 2007 20:21

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello James,

Well, it was introduced 2 days ago... So, you can try todays integration
build or next RC. :-)

-----------------
Alex Shatalin

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #131810 is a reply to message #131808]

Fri, 01 June 2007 22:47

Eclipse User

Originally posted by: james.willans.xactium.com

Thanks Alex. Are you saying that this code will solve the problem I
reported? If so, is there any chance you could post the code here so that
I can understand the new behaviour?

James

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #132067 is a reply to message #131810]

Mon, 04 June 2007 09:38

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello James,

This code can give you a hint how to implement "delete view" functionality.
Concerning example - it is in CVS. Just download latest Ecore diagram, example
(dev.eclipse.org /cvsroot/modeling org.eclipse.gmf/examples/org.eclipse.gmf.ecore.editor)
and open org.eclipse.gmf.ecore.edit.policies.EcoreBaseItemSemanticEdi tPolicy.

-----------------
Alex Shatalin

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #132266 is a reply to message #132067]

Mon, 04 June 2007 11:46

Eclipse User

Originally posted by: james.willans.xactium.com

Thanks Alex - I appreciate your help, could you give me a bit more
information. Here is what I know:

o The error occurs when two or more diagram on the same editing domain
contains a model element that is deleted from the one of the diagrams
using "delete from model". It doesn't occur with a single diagram,
therefore the error is caused by 2..n diagram

o That CanonicalEditPolicy is responsible for monitoring and
synchronisation changes that occur to the model which originated from
outside the diagram.

From what you have said, it seems that the model element view in the
second diagram is not getting removed as a result of the semantic element
deletion. This is entirely consistent with the error that I am seeing,
since the diagram editor is attempting to update a view which renders the
deleted semantic element. The CanonicalEditPolicy seems to have a
mechanism in place that deals with the removal of orphaned views in
refreshSemanticChildren(). Since this is not called during the "delete
from model", it suggest that the update which causes the exception is
being called before CanonicalEditPolicy::refresh() has taken placed?

The code you have pointed me to in ..BaseItemSemanticEditPolicy seems to
deal with the deletion of shortcuts. My understanding is that
..BaseItemSemanticEditPolicy creates requests and commands as a result of
user interaction with the diagram (whereas CanonicalEditPolicy does the
same for changes to the model outside of the diagram). So I'm confused:

o It doesn't seem logical to add further code to CanonicalEditPolicy,
since it seems to be doing its job, but it is not called in time.

o It doesn't seem logical to add further code to
..BaseItemSemanticEditPolicy since the problem occurs as a result of a
diagram not synchronising with its model, and this policy is doing a
different job.

Can you give me some guidance please? I have included the full exception
trace below.

Thanks,

James

Getting: 4 from: org.eclipse.emf.ecore.impl.EClassImpl@12e0e2f (name:
BS_Model) (instanceClassName: null) (abstract: false, interface: false)
eFeature: null
java.lang.NullPointerException
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSettingDelegate (BasicEObjectImpl.java:1526)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1019)
at BS.impl.BS_ModelImpl.eGet(BS_ModelImpl.java:115)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:1002)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:994)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjec tImpl.java:989)
at
BS.diagram.providers.BSStructuralFeatureParser.getStringByPa ttern(BSStructuralFeatureParser.java:81)
at
BS.diagram.providers.BSStructuralFeatureParser.getStringByPa ttern(BSStructuralFeatureParser.java:73)
at
BS.diagram.providers.BSAbstractParser.getPrintString(BSAbstr actParser.java:110)
at
BS.diagram.edit.parts.AK_kindEditPart.getLabelText(AK_kindEd itPart.java:208)
at
BS.diagram.edit.parts.AK_kindEditPart.refreshLabel(AK_kindEd itPart.java:417)
at
BS.diagram.edit.parts.AK_kindEditPart.refreshVisuals(AK_kind EditPart.java:406)
at
BS.diagram.edit.parts.AK_kindEditPart.setLabel(AK_kindEditPa rt.java:170)
at BS.diagram.edit.parts.AKEditPart.addFixedChild(AKEditPart.ja va:128)
at BS.diagram.edit.parts.AKEditPart.addChildVisual(AKEditPart.j ava:153)
at
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:197)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.addChild(GraphicalEditPart.java:1260)
at
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:727)
at
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:677)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphicalEditPart.java:554)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.access$3(GraphicalEditPart.java:1)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt$3.run(GraphicalEditPart.java:829)
at
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.runExclusive(TransactionalEditingDomainImpl.java:260)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.refresh(GraphicalEditPart.java:819)
at
org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:235)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphicalEditPart.java:212)
at
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:198)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.addChild(GraphicalEditPart.java:1260)
at
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:727)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.refreshChild(GraphicalEditPart.java:1173)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.handleMajorSemanticChange(GraphicalEditPart.java:1199)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeEditPart.h andleNotificationEvent(ShapeEditPart.java:93)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.ShapeNodeEditPa rt.handleNotificationEvent(ShapeNodeEditPart.java:225)
at
BS.diagram.edit.parts.AKEditPart.handleNotificationEvent(AKE ditPart.java:260)
at
org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPa rt.notifyChanged(GraphicalEditPart.java:1379)
at
org.eclipse.gmf.runtime.diagram.core.listener.DiagramEventBr oker.fireNotification(DiagramEventBroker.java:471)
at
org.eclipse.gmf.runtime.diagram.core.listener.DiagramEventBr oker.resourceSetChanged(DiagramEventBroker.java:382)
at
org.eclipse.gmf.runtime.diagram.ui.internal.DiagramEventBrok erThreadSafe.resourceSetChanged(DiagramEventBrokerThreadSafe .java:72)
at
org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFac tory$DiagramEditingDomain.postcommit(DiagramEditingDomainFac tory.java:213)
at
org.eclipse.emf.transaction.impl.TransactionalEditingDomainI mpl.deactivate(TransactionalEditingDomainImpl.java:473)
at
org.eclipse.emf.transaction.impl.TransactionImpl.close(Trans actionImpl.java:530)
at
org.eclipse.emf.transaction.impl.TransactionImpl.commit(Tran sactionImpl.java:371)
at
org.eclipse.emf.workspace.AbstractEMFOperation.execute(Abstr actEMFOperation.java:138)
at
org.eclipse.core.commands.operations.DefaultOperationHistory .execute(DefaultOperationHistory.java:509)
at
org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack .execute(DiagramCommandStack.java:193)
at
org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack .execute(DiagramCommandStack.java:168)
at
org.eclipse.gmf.runtime.diagram.ui.actions.DiagramAction.exe cute(DiagramAction.java:141)
at
org.eclipse.gmf.runtime.diagram.ui.actions.DiagramAction.doR un(DiagramAction.java:103)
at
org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandl er.run(AbstractActionHandler.java:359)
at
org.eclipse.gmf.runtime.common.ui.action.ActionManager$1.run (ActionManager.java:225)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
at
org.eclipse.gmf.runtime.common.ui.action.ActionManager.run(A ctionManager.java:223)
at
org.eclipse.gmf.runtime.common.ui.action.AbstractActionHandl er.runWithEvent(AbstractActionHandler.java:377)
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:545)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:490)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:402)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3490)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3104)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2264)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2228)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 03)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:457)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:289)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:452)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at com.xactium.bms.Application.start(Application.java:20)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:146)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:354)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 476)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
at org.eclipse.equinox.launcher.Main.run(Main.java:1124)
at org.eclipse.equinox.launcher.Main.main(Main.java:1099)
A

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #132379 is a reply to message #132266]

Mon, 04 June 2007 13:05

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello James,

> o The error occurs when two or more diagram on the same editing domain
> contains a model element that is deleted from the one of the diagrams
> using "delete from model". It doesn't occur with a single diagram,
> therefore the error is caused by 2..n diagram
True. The problem appears as a result of following sequence on calls:
1. DestroyElementCommand called. As a result underlying domain model element
removed. “Removed” means – .unset??() method called for all the references
to this element existing in model.
2. In addition to 1. Corresponding View instance and all the children of
this View will be removed (see DeleteCommand).
3. Since you have several diagrams opened in the same editing domain you
have additional View instances referencing same domain model element and
these instances will not be removed on step 2 (not child elements of the
view to be removed).
As a result of step 3. you are getting View instances without underlying
domain model element specified – incorrect state of the notation model.

For me it looks logical to remove all the additional necessary while executing
steps 1-3. The problem is: in generic situation GMF can not know anything
about additional views and diagrams loaded into the same EditingDomain (by
default generated code work with separate editing domains..) So, this is
a responsibility of the “tool smith” to modify templates/generated code in
accordance.

> o That CanonicalEditPolicy is responsible for monitoring and
> synchronisation changes that occur to the model which originated from
> outside the diagram.
In general you can modify generated CanonicalEditPolicy to remove all the
view instances with “unset” domain model elements. For me this contract is
not so clear, so I do not think that generic code should do something with
Views with “unset” elements.. In addition, CanonicalEditPolicy of the second
diagram will not receive notification in this case – only corresponding view
will receive a notification that underlying domain model element was “unset”.

> .BaseItemSemanticEditPolicy creates requests and commands as a result
> of user interaction with the diagram (whereas CanonicalEditPolicy does
> the same for changes to the model outside of the diagram). So I'm
In GMF we suppose that each executed command is responsible for complete
and valid model state after the command execution, so “valid” delete command
should remove domain model element and all the necessary View instances..
In your case – instances from the second diagram.

> o It doesn't seem logical to add further code to
> .BaseItemSemanticEditPolicy since the problem occurs as a result of a
> diagram not synchronising with its model, and this policy is doing a
> different job.
I think, the correct place for this logic is generated ???ItemSemanticEditpolicy.
getDestroyElementCommand().

-----------------
Alex Shatalin

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #132465 is a reply to message #132379]

Mon, 04 June 2007 14:34

Eclipse User

Originally posted by: james.willans.xactium.com

Alex - Thanks again. What your saying makes a lot of sense, particularly
about ensuring that everything is left in a complete state by the end of
the transaction execution.

What I simply don't understand is how I can destroy views in other
diagrams from a ???ItemSemanticEditpolicy. getDestroyElementCommand(). As
you say, a given diagram does not know about other diagrams sharing the
EditingDomain.

If it helps, the child label edit part causing all the problem has an
AbstractEnumerator semantic element.

James

Report message to a moderator

Re: Exception on delete from fully synchronised diagram [message #132520 is a reply to message #132465]

Mon, 04 June 2007 16:16

Alexander Shatalin

Messages: 2928
Registered: July 2009

Senior Member

Hello James,

Can you please submitt a bugzilla entry describing exception - we should
remove it in any case...

> What I simply don't understand is how I can destroy views in other
> diagrams from a ???ItemSemanticEditpolicy. getDestroyElementCommand().
> As you say, a given diagram does not know about other diagrams sharing
> the EditingDomain.
There should be a central place dispatching the same editing domain for all
the diagrams (DocumentProvider ?). I suppose this place is a "knowledge holder",
so you can query it and get all the diagrams openned with this editing domain
now..

-----------------
Alex Shatalin

Report message to a moderator

Previous Topic:	How to get editorInput without openning file in diagram editor
Next Topic:	Shortcuts Layout

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Sep 20 14:31:01 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter