Skip to main content


Eclipse Community Forums

      Home
Home » Modeling » Compare » CDO cannot find EClassifier after diffs are merged and about to be committed
CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006626] Fri, 01 February 2013 04:15 Go to next message
Eclipse UserFriend
I am trying to use EMF Compare to merge changes in a CDO application.
Just before committing my dirty transaction, I get the following error message:

Caused by: org.eclipse.emf.cdo.util.DanglingReferenceException: The object "org.eclipse.emf.ecore.impl.EClassImpl@113b61d (eProxyURI: http://example.com/myuri#//MyType)(org.eclipse.emf.ecore.impl.EClassImpl)" is not contained in a resource
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.provideCDOID(AbstractCDOView.java:1139)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.provideCDOID(CDOTransactionImpl.java:2237)
	at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writeValues(BaseCDORevision.java:893)


The problem is due to my model containing references to meta model elements (i.e. references to EClasses in my meta model).

Do you have any hints where to look at and/or what to debug?
Re: CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006642 is a reply to message #1006626] Fri, 01 February 2013 05:04 Go to previous messageGo to next message
Eclipse UserFriend
BTW: this is my compare code:

        final IComparisonScope scope = EMFCompare.createDefaultScope(left, right);
        Comparison comparison = EMFCompare.builder().build().compare(scope);

        final List<Diff> diffs = comparison.getDifferences();

        for (Diff diff : diffs) {
          diff.copyRightToLeft();
        }


The left object is an object obtained from CDO, the right object is an object obtained from a XMIResource (xmi file).
I want to apply all changes from the xmi file to the objects in the CDO repository.
It all seems to work well but I get errors EClasses are referenced in the model.
Re: CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006645 is a reply to message #1006626] Fri, 01 February 2013 05:10 Go to previous messageGo to next message
Eclipse UserFriend
Hi,

Which version of EMF Compare are you using? How (are you calling EMF Compare programmatically, if yes, is it in a standalone application)?

Some of our adopters are heavily relying on CDO, and they did not observe such issues. That's for EMF Compare 2.1 though. Can you try using one of the latest builds to check whether you reproduce (The stable 2.1.0M4 build can be installed from this update site)?

Laurent Goubet
Obeo
Re: CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006651 is a reply to message #1006645] Fri, 01 February 2013 05:29 Go to previous messageGo to next message
Eclipse UserFriend
I am using GIT sources from master (for both CDO and EMF Compare).
I am calling EMF Compare programmatically in an Eclipse RCP application.
The EPackage.Registry.INSTANCE seems to be set up properly (all EPackages registered).
Re: CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006652 is a reply to message #1006645] Fri, 01 February 2013 05:30 Go to previous messageGo to next message
Eclipse UserFriend
Never mind, you've answered some of my questions with the post you've added while I was writing Smile.

I believe that the issue comes from a mix of reasons. You are comparing things that come from different sources : one is an XMI resource you've loaded from the disk, the other is already a CDO object. The URIs used by both for their references will be different. EMF Compare will never resolve proxies by itself : something that is a proxy is out of the comparison scope. It seems that "MyType" is in such a case : "eProxyURI: http://example.com/myuri#//MyType" means that it has not been resolved; thus it is out of the scope.

Basically, if you tell EMF Compare that the comparison scope is only the two given EObjects ("right" and "left" in your example), then anything outside of these two objects will be neither matched nor differenced... let alone resolved. Because of that, "MyType" will not be matched. That would not cause any harm if your two objects were from the same source; but since one is CDO, the other is XMI loading... the Proxy URIs pointing towards "MyType" are distinct on both sides. Since we can only compare proxies through their URIs, we cannot tell that this is an object that should not be copied to the left, but rather referenced directly.

You will need to either change your approach so that all of your cross references are resolved and within the comparison scope, or extend the default behavior of EMF Compare to handle the comparison of your proxies by yourself. This can be done by replacing the EqualityHelper with something similar to this code.

Laurent Goubet
Obeo
Re: CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006661 is a reply to message #1006652] Fri, 01 February 2013 06:04 Go to previous messageGo to next message
Eclipse UserFriend
The problems exist with references to meta model elements:

EClass MyType
- some features...

EClass MyOtherType
- myType: EClass

I.e. the serialized object of type MyOtherType has a reference to the EClassifier MyType (not an instance of MyType).
Shouldn't EMF Compare be able to automatically resolve references to the EClass here?

Or: how would I make all my cross refs be resolved (at once)? Do you know of a simple call?

Laurent Goubet wrote on Fri, 01 February 2013 11:30
Never mind, you've answered some of my questions with the post you've added while I was writing Smile.

I believe that the issue comes from a mix of reasons. You are comparing things that come from different sources : one is an XMI resource you've loaded from the disk, the other is already a CDO object. The URIs used by both for their references will be different. EMF Compare will never resolve proxies by itself : something that is a proxy is out of the comparison scope. It seems that "MyType" is in such a case : "eProxyURI: http://example.com/myuri#//MyType" means that it has not been resolved; thus it is out of the scope.

Basically, if you tell EMF Compare that the comparison scope is only the two given EObjects ("right" and "left" in your example), then anything outside of these two objects will be neither matched nor differenced... let alone resolved. Because of that, "MyType" will not be matched. That would not cause any harm if your two objects were from the same source; but since one is CDO, the other is XMI loading... the Proxy URIs pointing towards "MyType" are distinct on both sides. Since we can only compare proxies through their URIs, we cannot tell that this is an object that should not be copied to the left, but rather referenced directly.

You will need to either change your approach so that all of your cross references are resolved and within the comparison scope, or extend the default behavior of EMF Compare to handle the comparison of your proxies by yourself. This can be done by replacing the EqualityHelper with something similar to this code.

Laurent Goubet
Obeo
Re: CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006674 is a reply to message #1006661] Fri, 01 February 2013 06:56 Go to previous messageGo to next message
Eclipse UserFriend
FYI: this code resolves all proxies:

          TreeIterator<EObject> eAllContents = right.eAllContents();
          while (eAllContents.hasNext()) {
            EObject next = eAllContents.next();
            
            for (EObject cr : next.eCrossReferences()) {
              cr.eIsProxy();
            }
          }
Re: CDO cannot find EClassifier after diffs are merged and about to be committed [message #1007269 is a reply to message #1006674] Tue, 05 February 2013 05:20 Go to previous message
Eclipse UserFriend
Hi,

Quote:
Shouldn't EMF Compare be able to automatically resolve references to the EClass here?


It's not that EMF Compare cannot. It does not. Most EMF tools see proxies as a mere implementation detail and simply let EMF resolve everything by default. EMF Compare is designed to handle very large models, even models that would not fit in the memory, as long as they are properly fragmented : we consider proxies to be out of the comparison scope, and will thus never resolve them.

So either you resolve the proxies yourself, as you did here, if they hold no real meaning to you (i.e. your models are small or you do not need them properly fragmented), or you tell EMF Compare how to handle your own proxies as I hinted in my previous post. No choice is really "better" than the other, it really depends on your use case Smile.

Laurent Goubet
Obeo
Previous Topic:EMFCompare graph structure and change information
Next Topic:Use Compare to resolve/merge CDO conflicts
Goto Forum:
  


Current Time: Mon Jul 07 21:22:00 EDT 2025

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly