Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF command redo returns uncomplete Graphiti diagram
EMF command redo returns uncomplete Graphiti diagram [message #1462571] Wed, 05 November 2014 18:28 Go to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi all,

I recently posted a topic in the Graphiti forum :
https://www.eclipse.org/forums/index.php/t/842301/

But, while investigating my problem, I started to think the explanation could be on the EMF side.
Graphiti diagrams are EMF models that I choose to store in CDO.

Starting from an empty diagram displayed as the following array by the debugger :
[null, [], [], null, [], [Color@OID70, Color@OID71], null, []]


I add an element to my diagram :
[[], [], [ContainerShape@oid1[NEW]], null, [], [Color@OID70, Color@OID71, Color@oid3[NEW], Color@oid4[NEW], Color@oid12[NEW]], [Font@oid13[NEW]], [PictogramLink@oid5[NEW], PictogramLink@oid14[NEW]]]


I can then perform an undo :
[[], [], [], null, [], [Color@OID70, Color@OID71], [], []]


But the redo fails as some elements are not added back to the diagram :
[[], [], [], null, [], [Color@OID70, Color@OID71, Color@oid17[NEW], Color@oid18[NEW], Color@oid19[NEW]], [], [PictogramLink@oid21[NEW], PictogramLink@oid24[NEW]]]

Colors and pictogram links have correctly been added back (with their new cdo IDs) but the container shape and the font objects are missing...

Graphiti undo and redo are based on the EMF command ones.
Following the EMF calling stack down to ChangeDescriptionImpl.applyAndReverse, objectChanges and objectsToAttach lists seem to contain all the expected objects.

But, after the call of FeatureChangeImpl.process, it seems that some objects are not added to objectsBeforeApply and objectsAfterApply. And they correspond to the missing ones after redo.

As the Graphiti tutorial works fine with redo, I guess the problem results from modifications I made to graphiti.ecore and / or graphiti.genmodel (see attached files).

In the ecore model, I added an DiagramMetaData class that is now referenced by the Diagram class.
In the genmodel, I made the modifications to become CDO compliant according to the corresponding CDO wiki.

I hope someone can tell me what is it I did wrong...

Kind regards,

Laurent
Re: EMF command redo returns uncomplete Graphiti diagram [message #1464299 is a reply to message #1462571] Fri, 07 November 2014 11:55 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30550
Registered: July 2009
Senior Member
Laurent,

Sorry, there are too many technologies involved that I can just answer
something like this looking at a *.ecore...

On 05/11/2014 7:28 PM, Laurent Le Moux wrote:
> Hi all,
>
> I recently posted a topic in the Graphiti forum :
> https://www.eclipse.org/forums/index.php/t/842301/
>
> But, while investigating my problem, I started to think the explanation could be on the EMF side.
> Graphiti diagrams are EMF models that I choose to store in CDO.
>
> Starting from an empty diagram displayed as the following array by the debugger :
>
> [null, [], [], null, [], [Color@OID70, Color@OID71], null, []]
>
>
> I add an element to my diagram :
>
> [[], [], [ContainerShape@oid1[NEW]], null, [], [Color@OID70, Color@OID71, Color@oid3[NEW], Color@oid4[NEW], Color@oid12[NEW]], [Font@oid13[NEW]], [PictogramLink@oid5[NEW], PictogramLink@oid14[NEW]]]
>
>
> I can then perform an undo :
>
> [[], [], [], null, [], [Color@OID70, Color@OID71], [], []]
>
>
> But the redo fails as some elements are not added back to the diagram :
>
> [[], [], [], null, [], [Color@OID70, Color@OID71, Color@oid17[NEW], Color@oid18[NEW], Color@oid19[NEW]], [], [PictogramLink@oid21[NEW], PictogramLink@oid24[NEW]]]
>
> Colors and pictogram links have correctly been added back (with their new cdo IDs) but the container shape and the font objects are missing...
>
> Graphiti undo and redo are based on the EMF command ones.
> Following the EMF calling stack down to ChangeDescriptionImpl.applyAndReverse, objectChanges and objectsToAttach lists seem to contain all the expected objects.
>
> But, after the call of FeatureChangeImpl.process, it seems that some objects are not added to objectsBeforeApply and objectsAfterApply. And they correspond to the missing ones after redo.
>
> As the Graphiti tutorial works fine with redo, I guess the problem results from modifications I made to graphiti.ecore and / or graphiti.genmodel (see attached files).
>
> In the ecore model, I added an DiagramMetaData class that is now referenced by the Diagram class.
> In the genmodel, I made the modifications to become CDO compliant according to the corresponding CDO wiki.
>
> I hope someone can tell me what is it I did wrong...
>
> Kind regards,
>
> Laurent
[CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1464532 is a reply to message #1464299] Fri, 07 November 2014 17:12 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi Ed,

You're right... I followed the calling stack and - to make it short - the problem seems to be on CDO side. Is there a way to add the [CDO] prefix to my topic title ?

Adding a shape to my Graphiti diagram is ok. Undo is also Ok. But redo fails with a dirty but empty diagram.

So, I had a deeper look at the redo processing.
Redoing the add command basically leads to three major steps in the EMF (generic) execution :
- First add back the shape to the diagram.
- As the Graphiti ecore model defines an 'EOpposite' reference, an 'inverseAdd' is then executed which leads to the removal of the shape from the diagram.
- Finally, the diagram is set as the shape container again.

Each steps leads to a call of CDOStateMachine$WriteTransition.execute which takes care of updating the CDO objects 'diagram' and 'shape' accordingly.
Except for the last step...

Setting the diagram as the shape container leads to the call of CDOStateMachine$WriteNewTransition.execute which, in turn, calls CDOContainerFeatureDeltaImpl.applyTo.

And this method is apparently not updating the diagram to hold the shape reference as expected...

  public Object applyTo(CDORevision revision)
  {
    InternalCDORevision internalRevision = (InternalCDORevision)revision;
    internalRevision.setResourceID(newResourceID);
    internalRevision.setContainerID(newContainerID);
    internalRevision.setContainingFeatureID(newContainerFeatureID);
    return null;
  }


If I'm right, what would the workaround be ? Simply returning internalRevision in the debug mode is not working ?

Regards,

Laurent

[Updated on: Fri, 07 November 2014 17:14]

Report message to a moderator

Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1470344 is a reply to message #1464532] Wed, 12 November 2014 09:09 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban DugueperouxFriend
Messages: 472
Registered: July 2009
Senior Member
Hi Laurent,

Which release of CDO do you use?
If you have the bug with the last one, could you write a JUnit test to
reproduce your issue?

Best Regards.

Le 07/11/2014 18:12, Laurent Le Moux a écrit :
> Hi Ed,
>
> You're right... I followed the calling stack and - to make it short -
> the problem seems to be on CDO side. That's the reason why I changed the
> topic title...
>
> Adding a shape to my Graphiti diagram is ok. Undo is also Ok. But redo
> fails with a dirty but empty diagram.
>
> So, I had a deeper look at the redo processing.
> Redoing the add command basically leads to three major steps in the EMF
> (generic) execution :
> - First add back the shape to the diagram.
> - As the Graphiti ecore model defines an 'EOpposite' reference, an
> 'inverseAdd' is then executed which leads to the removal of the shape
> from the diagram.
> - Finally, the diagram is set as the shape container again.
>
> Each steps leads to a call of CDOStateMachine$WriteTransition.execute
> which takes care of updating the CDO objects 'diagram' and 'shape'
> accordingly.
> Except for the last step...
>
> Setting the diagram as the shape container leads to the call of
> CDOStateMachine$WriteNewTransition.execute which, in turn, calls
> CDOContainerFeatureDeltaImpl.applyTo.
>
> And this method is apparently not updating the diagram to hold the shape
> reference as expected...
>
>
> public Object applyTo(CDORevision revision)
> {
> InternalCDORevision internalRevision = (InternalCDORevision)revision;
> internalRevision.setResourceID(newResourceID);
> internalRevision.setContainerID(newContainerID);
> internalRevision.setContainingFeatureID(newContainerFeatureID);
> return null;
> }
>
>
> If I'm right, what would the workaround be ? Simply returning
> internalRevision in the debug mode is not working ?
>
> Regards,
>
> Laurent



--
Esteban Dugueperoux - Obeo

Need professional services for Sirius?
http://www.obeodesigner.com/sirius
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1471755 is a reply to message #1470344] Thu, 13 November 2014 10:00 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi Esteban,

I'm using CDO Model Repository SDK 4.3.0.v20140606-1557.
I wrote a junit test to simulate the Graphiti add feature with undo and redo (see attached plugins).
But until now I fail to reproduce the problem...
Still searching...

Regards,

Laurent
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1471956 is a reply to message #1471755] Thu, 13 November 2014 13:33 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

I finally managed to reproduce the problem. Please use the new attached plugins.

I wrote two tests.
A passing one makes a redo based on EMF add commands.
Whereas the failing one does the same with these commands encapsulated in EMF transaction recording commands.

It leads to two different calling stacks.
The passing test does things like :
WriteTransition.execute -> CDOAddFeatureDeltaImpl.applyTo
and
WriteNewTransition.execute->CDOSetFeatureDeltaImpl.applyTo

The Failing test, at some point, does :
WriteNewTransition.execute->CDOContainerFeatureDeltaImpl.applyTo
As previously described in this topic.

So my questions are :
- Why are the calling stacks different ?
- What's wrong with the second one which causes the redo to fail with a uncomplete dirty diagram ?

Kind regards,

Laurent
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1488155 is a reply to message #1471956] Wed, 26 November 2014 11:03 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

I'm still struggling with my failing redo problem. I tried another approach, starting from the Graphiti tutorial which works fine with undo/redo.

I cloned the graphiti project from https://git.eclipse.org/gitroot/graphiti/org.eclipse.graphiti
And imported just the necessary plugins to have the Graphiti tutorial example running.

Adding a few 'generated NOT' where needed and changing the feature delegation to 'reflective' in the genmodel is not a problem. Redo is still working.

But, when I further adapt the genmodel for CDO :
Model Plug-in Variables : CDO=org.eclipse.emf.cdo
Root Extends Class = org.eclipse.emf.internal.cdo.CDOObjectImpl
Root Extends Interface = org.eclipse.emf.cdo.CDOObject
The problem shows up...

Changing the Root Extends Class to CDOObjectImpl and leaving the EObject root interface also causes the redo to fail.

In this second test, I don't even connect to a CDO repository because I was expecting the behavior to stick to the EObject one as long as I don't try to commit anything...

I attached the modified Graphiti plugins and I really hope that somebody can help because I'm stuck Sad

Kind regards,

Laurent
  • Attachment: Graphiti.zip
    (Size: 2.66MB, Downloaded 64 times)
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1488438 is a reply to message #1488155] Wed, 26 November 2014 16:01 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
One more information. Debugging the Graphiti tutorial example with no CDO repository leads to the use of an underlying CDOObjectImpl$TransientStore instead of a CDOStoreImpl, which looks normal.

And the store is apparently relying on a BasicEList to assign values like in EObject context where redo works just fine.

So, I don't understand why it does not work in that transient context either...
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1489533 is a reply to message #1488438] Thu, 27 November 2014 12:59 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

Apparently (not sure...), it seems the problem could be the EOpposite reference defined between the Graphiti diagram and the shape I want to add back with a redo.

I defined a simplistic ecore model (see attached project) where a Container and an InnerElement classes are referencing each other in a "EOpposite way".
I then basically generated the model code based on EObjects.

So, neither Graphiti, nor CDO are involved.
I then wrote a simple junit test to have a 'container' referencing an 'inner element' through a RecordingCommand following the "EMF Model Transaction Development Guide" :

http://www.linuxtopia.org/online_books/eclipse_documentation/eclipse_emf_model_transaction_developer_guide/topic/org.eclipse.emf.transaction.doc/references/overview/eclipse_emf_model_transaction_creating.html

This time, it is the undo that fails... The reference is not undone.

Could somebody tell me what's wrong ? Could it be linked to my first problem somehow ?

Regards,

Laurent
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1490918 is a reply to message #1489533] Fri, 28 November 2014 14:58 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

I had a look at the feature change objects during undo and redo in both EObject and CDOObject "contexts" (still using the Graphiti tutorial example for test).

I noticed "small" differences like a null pointer instead of an empty array (as I already pointed out at the beginning of this topic).
But the following difference did really attract my attention :

In case of a succesful redo based on EObjects, the shape that is contained in my diagram with an EOpposite reference, has the following feature change object :

feature = container (ERef), value = diagram, new value = null and an empty list of changes.

Whereas, for a failing redo based on CDOObjects, the shape has the following change object :

feature = container, value = diagram, new value = diagram, list of changes = null...

I don't know whether this could be the cause of my problem.
In the debugger, I forced new value = null but redo is still failing... Sad
And I have difficulties to find out where this feature change instance has been created.

Any idea of what happens ?

Regards,

Laurent
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1494569 is a reply to message #1490918] Mon, 01 December 2014 15:30 Go to previous messageGo to next message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Hi again,

It finally came back to my mind that CDO can also store legacy models...

So I gave it a try but it's only a partially functionning workaround Sad

I get redo working (!) but now an "interface org.eclipse.emf.cdo.view.CDOStaleObject is not visible from class loader" error shows up from time to time, either on the client or the server side.

To sum up, redo of a recording command from an EMF transactional editing domain command stack on the Graphiti legacy model is ok whereas it fails on a CDO adapted / native model.

I opened the following bug report concerning this point :

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

Concerning the class loader problem, I created a dedicated topic :

https://www.eclipse.org/forums/index.php/t/876970/

Regards,

Laurent
Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1494593 is a reply to message #1494569] Mon, 01 December 2014 15:54 Go to previous message
Laurent Le Moux is currently offline Laurent Le MouxFriend
Messages: 184
Registered: September 2011
Senior Member
Looking for a workaround now, is there a way to use a CDO native Graphiti model but have the redo being executed as with the EObjects of the legacy model ?

Is it possible - for instance - to execute this "shunt" by invoking CDOUtil.getEObject() at some convenient place ?
Previous Topic:[CDO] interface CDOStaleObject not visible from class loader for legacy model
Next Topic:How to serialze intrinsic ids as attributes?
Goto Forum:
  


Current Time: Wed Oct 16 17:58:16 GMT 2019

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

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

Back to the top