Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Undo Problem: AppliedStereotypeCommentEditPolicy
Undo Problem: AppliedStereotypeCommentEditPolicy [message #1726930] Thu, 17 March 2016 14:25 Go to next message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 309
Registered: February 2012
Location: Düsseldorf
Senior Member
Hi,
when using Papyrus together with CDO the following operations results in a

org.eclipse.emf.cdo.util.DanglingIntegrityException




  1. Create a Class in a Diagram
  2. Add a Stereotype (e.g. Block)
  3. Remove the class from the diagram
  4. Undo the remove


It turns out that the undo operation performed by the command stack is incomplete because some of the diagram rendering operations bypass the command stack. As a result the objects which were created bypassing the command stack are dangling after the undo.

We have debugged the code and found that the following code is executed when the Block is rendered in the Diagram:

	protected void executeAppliedStereotypeCommentCreation(final EObject node) {

		final TransactionalEditingDomain domain = hostEditPart.getEditingDomain();
		Display.getCurrent().syncExec(new Runnable() {

			public void run() {
				int x = 200;
				int y = 100;
				if (hostEditPart.getModel() instanceof Node) {
					LayoutConstraint constraint = ((Node) hostEditPart.getModel()).getLayoutConstraint();
					if (constraint instanceof Bounds) {
						x = x + ((Bounds) constraint).getX();
						y = ((Bounds) constraint).getY();
					}

				}
				if (hostEditPart.getModel() instanceof Edge && ((((Edge) hostEditPart.getModel()).getSource()) instanceof Node)) {

					LayoutConstraint constraint = ((Node) ((Edge) hostEditPart.getModel()).getSource()).getLayoutConstraint();
					if (constraint instanceof Bounds) {
						x = x + ((Bounds) constraint).getX();
						y = ((Bounds) constraint).getY() - 100;
					}

				}
				boolean isBorderElement = false;
				if (hostEditPart instanceof BorderedBorderItemEditPart) {
					isBorderElement = true;
				}
				if (helper.getStereotypeComment((View) getHost().getModel()) == null) {
					CreateAppliedStereotypeCommentViewCommand command = new CreateAppliedStereotypeCommentViewCommand(domain, (View) hostEditPart.getModel(), x, y, node, isBorderElement);
					// use to avoid to put it in the command stack
					try {
						GMFUnsafe.write(domain, command);
					} catch (Exception e) {
						Activator.log.error(e);
					}
				}
			}

		});
	}


As the comment states, the GMFUnsafe.write(domain, command); executes the command by-passing the command stack. The CreateAppliedStereotypeCommentViewCommand itself calls

connectCommentNode()


which while being executed calls:

ViewUtil.insertChildView(econtainer, commentNode, ViewUtil.APPEND, true),


where the last parameter indicates that the commendNode should be persisted.

From looking into the CDO-Database we can see, that the node is really persisted. The undo operation leads to a situation in which the node is still referenced from somewhere without being contained:

org.eclipse.net4j.util.transaction.TransactionException: org.eclipse.emf.cdo.util.DanglingIntegrityException: The object "CDOLegacyAdapter[CSSShapeImpl@null](org.eclipse.emf.internal.cdo.object.CDOLegacyAdapter)" is not contained in a resource
               at org.eclipse.emf.cdo.eresource.impl.CDOResourceImpl.save(CDOResourceImpl.java:1336)
               at org.eclipse.papyrus.infra.core.resource.EMFLogicalModel.saveModel(EMFLogicalModel.java:80)
               at org.eclipse.papyrus.infra.core.resource.ModelSet.save(ModelSet.java:773)
               at org.eclipse.papyrus.cdo.core.resource.CDOAwareModelSet.save(CDOAwareModelSet.java:422)
               at org.eclipse.papyrus.infra.core.lifecycleevents.SaveAndDirtyService.doSave(SaveAndDirtyService.java:286)
               at org.eclipse.papyrus.infra.core.editor.CoreMultiDiagramEditor.doSave(CoreMultiDiagramEditor.java:980)
               at org.eclipse.ui.internal.SaveableHelper$2.run(SaveableHelper.java:156)
               at org.eclipse.ui.internal.SaveableHelper$5.run(SaveableHelper.java:285)
               at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:463)
               at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:371)
               at org.eclipse.ui.internal.WorkbenchWindow$14.run(WorkbenchWindow.java:2156)
               at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
               at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2152)


Could someone give me a hint what is going on here? Is the StereotypeCommentView meant to be persisted or not? If so why is the command stack bypassed which results in an incorrect undo?

Thanks a lot in advance
Thorsten

[Updated on: Fri, 18 March 2016 08:55]

Report message to a moderator

Re: Undo Problem: AppliedStereotypeCommentEditPolicy [message #1727419 is a reply to message #1726930] Tue, 22 March 2016 23:50 Go to previous messageGo to next message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 309
Registered: February 2012
Location: Düsseldorf
Senior Member
Hi,
we have now checked the situation with the standalone Papyrus. The situation is the same. The CDO issue is only raised because the Repository checks the referential integrity of the model which is not done in standalone Papyrus.

This is how the diagram looks after creation of a class with stereotype block:

<?xml version="1.0" encoding="UTF-8"?>
<notation:Diagram xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:notation="http://www.eclipse.org/gmf/runtime/1.0.2/notation" xmlns:style="http://www.eclipse.org/papyrus/infra/viewpoints/policy/style" xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML" xmi:id="_DMW-UPAaEeWxSdpA06l4tA" type="PapyrusUMLClassDiagram" name="ClassDiagram" measurementUnit="Pixel">
  <children xmi:type="notation:Shape" xmi:id="_Dm_r4PAaEeWxSdpA06l4tA" type="2008">
    <children xmi:type="notation:DecorationNode" xmi:id="_Dm_r4vAaEeWxSdpA06l4tA" type="5029"/>
    <children xmi:type="notation:DecorationNode" xmi:id="_Dm_r4_AaEeWxSdpA06l4tA" type="8510">
      <layoutConstraint xmi:type="notation:Location" xmi:id="_Dm_r5PAaEeWxSdpA06l4tA" y="5"/>
    </children>
    <children xmi:type="notation:BasicCompartment" xmi:id="_Dm_r5fAaEeWxSdpA06l4tA" type="7017">
      <styles xmi:type="notation:TitleStyle" xmi:id="_Dm_r5vAaEeWxSdpA06l4tA"/>
      <styles xmi:type="notation:SortingStyle" xmi:id="_Dm_r5_AaEeWxSdpA06l4tA"/>
      <styles xmi:type="notation:FilteringStyle" xmi:id="_Dm_r6PAaEeWxSdpA06l4tA"/>
      <layoutConstraint xmi:type="notation:Bounds" xmi:id="_Dm_r6fAaEeWxSdpA06l4tA"/>
    </children>
    <children xmi:type="notation:BasicCompartment" xmi:id="_Dm_r6vAaEeWxSdpA06l4tA" type="7018">
      <styles xmi:type="notation:TitleStyle" xmi:id="_Dm_r6_AaEeWxSdpA06l4tA"/>
      <styles xmi:type="notation:SortingStyle" xmi:id="_Dm_r7PAaEeWxSdpA06l4tA"/>
      <styles xmi:type="notation:FilteringStyle" xmi:id="_Dm_r7fAaEeWxSdpA06l4tA"/>
      <layoutConstraint xmi:type="notation:Bounds" xmi:id="_Dm_r7vAaEeWxSdpA06l4tA"/>
    </children>
    <children xmi:type="notation:BasicCompartment" xmi:id="_Dm_r7_AaEeWxSdpA06l4tA" type="7019">
      <styles xmi:type="notation:TitleStyle" xmi:id="_Dm_r8PAaEeWxSdpA06l4tA"/>
      <styles xmi:type="notation:SortingStyle" xmi:id="_Dm_r8fAaEeWxSdpA06l4tA"/>
      <styles xmi:type="notation:FilteringStyle" xmi:id="_Dm_r8vAaEeWxSdpA06l4tA"/>
      <layoutConstraint xmi:type="notation:Bounds" xmi:id="_Dm_r8_AaEeWxSdpA06l4tA"/>
    </children>
    <element xmi:type="uml:Class" href="model.uml#_Dm8okPAaEeWxSdpA06l4tA"/>
    <layoutConstraint xmi:type="notation:Bounds" xmi:id="_Dm_r4fAaEeWxSdpA06l4tA" x="596" y="194"/>
  </children>
  <children xmi:type="notation:Shape" xmi:id="_EkxiwPAaEeWxSdpA06l4tA" type="StereotypeComment">
    <styles xmi:type="notation:TitleStyle" xmi:id="_EkxiwfAaEeWxSdpA06l4tA" showTitle="true"/>
    <styles xmi:type="notation:EObjectValueStyle" xmi:id="_EkyJ0PAaEeWxSdpA06l4tA" name="BASE_ELEMENT">
      <eObjectValue xmi:type="uml:Class" href="model.uml#_Dm8okPAaEeWxSdpA06l4tA"/>
    </styles>
    <element xsi:nil="true"/>
    <layoutConstraint xmi:type="notation:Bounds" xmi:id="_EkxiwvAaEeWxSdpA06l4tA" x="796" y="194"/>
  </children>
  <styles xmi:type="notation:StringValueStyle" xmi:id="_DMW-UfAaEeWxSdpA06l4tA" name="diagram_compatibility_version" stringValue="1.1.0"/>
  <styles xmi:type="notation:DiagramStyle" xmi:id="_DMW-UvAaEeWxSdpA06l4tA"/>
  <styles xmi:type="style:PapyrusViewStyle" xmi:id="_DMW-U_AaEeWxSdpA06l4tA">
    <owner xmi:type="uml:Model" href="model.uml#__5F2wPAZEeWxSdpA06l4tA"/>
  </styles>
  <element xmi:type="uml:Model" href="model.uml#__5F2wPAZEeWxSdpA06l4tA"/>
  <edges xmi:type="notation:Connector" xmi:id="_EkyJ0fAaEeWxSdpA06l4tA" type="StereotypeCommentLink" source="_Dm_r4PAaEeWxSdpA06l4tA" target="_EkxiwPAaEeWxSdpA06l4tA">
    <styles xmi:type="notation:FontStyle" xmi:id="_EkyJ0vAaEeWxSdpA06l4tA"/>
    <styles xmi:type="notation:EObjectValueStyle" xmi:id="_EkyJ1vAaEeWxSdpA06l4tA" name="BASE_ELEMENT">
      <eObjectValue xmi:type="uml:Class" href="model.uml#_Dm8okPAaEeWxSdpA06l4tA"/>
    </styles>
    <element xsi:nil="true"/>
    <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_EkyJ0_AaEeWxSdpA06l4tA" points="[0, 0, 0, 0]$[0, 0, 0, 0]"/>
    <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_EkyJ1PAaEeWxSdpA06l4tA"/>
    <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_EkyJ1fAaEeWxSdpA06l4tA"/>
  </edges>
</notation:Diagram>



Note that two shapes are present. The second shape is due to the Block stereotype association. After deletion of the class, the file is expectedly more or less empty. After undo of the deletion it is possible to intercept the saving process in the ModelSet. By checking CrossReferences it becomes evident that the following uncontained shape

  <children xmi:type="notation:Shape" xmi:id="_EkxiwPAaEeWxSdpA06l4tA" type="StereotypeComment">
    <styles xmi:type="notation:TitleStyle" xmi:id="_EkxiwfAaEeWxSdpA06l4tA" showTitle="true"/>
    <styles xmi:type="notation:EObjectValueStyle" xmi:id="_EkyJ0PAaEeWxSdpA06l4tA" name="BASE_ELEMENT">
      <eObjectValue xmi:type="uml:Class" href="model.uml#_Dm8okPAaEeWxSdpA06l4tA"/>
    </styles>
    <element xsi:nil="true"/>
    <layoutConstraint xmi:type="notation:Bounds" xmi:id="_EkxiwvAaEeWxSdpA06l4tA" x="796" y="194"/>
  </children>


is still referenced by the target of this edge

 <edges xmi:type="notation:Connector" xmi:id="_EkyJ0fAaEeWxSdpA06l4tA" type="StereotypeCommentLink" source="_Dm_r4PAaEeWxSdpA06l4tA" target="_EkxiwPAaEeWxSdpA06l4tA">
    <styles xmi:type="notation:FontStyle" xmi:id="_EkyJ0vAaEeWxSdpA06l4tA"/>
    <styles xmi:type="notation:EObjectValueStyle" xmi:id="_EkyJ1vAaEeWxSdpA06l4tA" name="BASE_ELEMENT">
      <eObjectValue xmi:type="uml:Class" href="model.uml#_Dm8okPAaEeWxSdpA06l4tA"/>
    </styles>
    <element xsi:nil="true"/>
    <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_EkyJ0_AaEeWxSdpA06l4tA" points="[0, 0, 0, 0]$[0, 0, 0, 0]"/>
    <sourceAnchor xmi:type="notation:IdentityAnchor" xmi:id="_EkyJ1PAaEeWxSdpA06l4tA"/>
    <targetAnchor xmi:type="notation:IdentityAnchor" xmi:id="_EkyJ1fAaEeWxSdpA06l4tA"/>
  </edges>



This dangling references is deleted when the resource gets saved because this save option is used:

[code]
PROCESS_DANGLING_HREF=DISCARD
/code]

Due to this behaviour is is currently not possible to properly handle stereotypes in diagrams together with CDO when the Repository is configured to check referential integrity.

I will try to temporary patch this issue with a ResourceSetListener that removes the dangling reference upon undo but I think there is a general issue in Papyrus as CSSShape creation explicitly bypasses the command stack whereas the shape itself is added in a persistent manner. So this issue must probably be solved somewhere here

AppliedStereotypeCommentEditPolicy


and thereafter.

Any other thoughts are very much appreciated.

Regards,
Thorsten

Re: Undo Problem: AppliedStereotypeCommentEditPolicy [message #1727530 is a reply to message #1727419] Wed, 23 March 2016 14:26 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1206
Registered: July 2009
Location: Canada
Senior Member

Hi, Thorsten,

Thanks for the thorough analysis of this problem. I think this is a
bug, and have accordingly raised

https://bugs.eclipse.org/bugs/show_bug.cgi?id=490296

with the details that you have provided. In short, the unrecorded
manipulation of diagrams is only intended by GMF for transient views
(usually in canonical diagrams). And in any case code that does this
needs to account properly for undo/redo itself, because the editing
domain won't do that automatically.

I have provisionally tagged this bug with found-in version 1.1.0.
Which version of Papyrus are you using?

Thanks,

Christian
Re: Undo Problem: AppliedStereotypeCommentEditPolicy [message #1727534 is a reply to message #1727530] Wed, 23 March 2016 14:55 Go to previous message
Thorsten Schlathölter is currently offline Thorsten SchlathölterFriend
Messages: 309
Registered: February 2012
Location: Düsseldorf
Senior Member
Hi Christian,
thanks for answering. I have meanwhile raised a bug myself and just wanted to add it to this post.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=490254

We are using Version 1.1.1.

I will mark my bug as duplicate.
Previous Topic:Viewpoint new diagram menu greyed out
Next Topic:Changing the usecase-ellipse in a usecase diagramm
Goto Forum:
  


Current Time: Fri Jul 10 20:09:52 GMT 2020

Powered by FUDForum. Page generated in 0.05296 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top