CDO cannot find EClassifier after diffs are merged and about to be committed [message #1006626] |
Fri, 01 February 2013 04:15  |
Eclipse User |
|
|
|
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 #1006652 is a reply to message #1006645] |
Fri, 01 February 2013 05:30   |
Eclipse User |
|
|
|
Never mind, you've answered some of my questions with the post you've added while I was writing .
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   |
Eclipse User |
|
|
|
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:30Never mind, you've answered some of my questions with the post you've added while I was writing .
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
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.07092 seconds