| Undo Problem: AppliedStereotypeCommentEditPolicy [message #1726930] |
Thu, 17 March 2016 14:25  |
 Thorsten Schlathölter
Messages: 312
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
- Create a Class in a Diagram
- Add a Stereotype (e.g. Block)
- Remove the class from the diagram
- 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
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  |
Thorsten Schlathölter
Messages: 312
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 |
|
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03248 seconds
] 
Search
Help
Register
Login
Home
