Home » Modeling » TMF (Xtext) » [SOLVED] Strange EOpposite proxy resolving issue(Proxies are not correctly resolved.)
| [SOLVED] Strange EOpposite proxy resolving issue [message #1220627] |
Thu, 12 December 2013 18:46  |
 Jens Rabe
Messages: 81
Registered: September 2013 |
Member |
|
|
Sorry for cross-posting this, I already posted it in the EMF forum, but I figured out that this must be an Xtext issue. @Admin: Feel free to delete the other post.
I have two objects, A and B. A has a single-valued reference to B, B has a multi-valued reference to A. The references are set as EOpposites (A.b is EOpposite to B.a and vice-versa). They are both persisted to different files.
Now, there is a VERY strange problem:
I load A from a resource set. This gives me my A, and A.b points to a B which is a proxy. B.a points to A. Everything is OK for now.
However, I now access the B. The proxy B is resolved to B' which is the real object.
My expectation would now be:
A.b points to B', B'.a points to A.
But what happens is:
A.b points to B', B'.a points to a NEW proxy A', and A'.b points to B' again. When I now call the B'.a, the proxy A' is resolved to a "real" object A'', whereas A''.b points to a new proxy B'', and so forth. If I traverse this, I can go an endless path of incorrectly resolved objects.
What is going wrong here?
[Updated on: Fri, 13 December 2013 09:52] Report message to a moderator |
|
|
| Re: Strange EOpposite proxy resolving issue [message #1220693 is a reply to message #1220627] |
Fri, 13 December 2013 06:47  |
Ed Merks
Messages: 31253
Registered: July 2009 |
Senior Member |
|
|
Jens,
I answered this on the EMF forum. Nothing you describe here sounds
directly Xtext related... How is your issue related to Xtext specifically?
On 12/12/2013 7:46 PM, Jens Rabe wrote:
> Sorry for cross-posting this, I already posted it in the EMF forum,
> but I figured out that this must be an Xtext issue. @Admin: Feel free
> to delete the other post.
>
> I have two objects, A and B. A has a single-valued reference to B, B
> has a multi-valued reference to A. The references are set as
> EOpposites (A.b is EOpposite to B.a and vice-versa). They are both
> persisted to different files.
>
> Now, there is a VERY strange problem:
>
> I load A from a resource set. This gives me my A, and A.b points to a
> B which is a proxy. B.a points to A. Everything is OK for now.
>
> However, I now access the B. The proxy B is resolved to B' which is
> the real object.
>
> My expectation would now be:
> A.b points to B', B'.a points to A.
>
> But what happens is:
>
> A.b points to B', B'.a points to a NEW proxy A', and A'.b points to B'
> again. When I now call the B'.a, the proxy A' is resolved to a "real"
> object A'', whereas A''.b points to a new proxy B'', and so forth. If
> I traverse this, I can go an endless path of incorrectly resolved
> objects.
>
> What is going wrong here?
|
|
|
| Re: Strange EOpposite proxy resolving issue [message #1220724 is a reply to message #1220693] |
Fri, 13 December 2013 09:51 |
Jens Rabe
Messages: 81
Registered: September 2013 |
Member |
|
|
Hi, I solved the problem. It was partly Xtext and partly EMF related. Your first answer to the other post on saving dependent resources got me to the goal. My problem was the scoping, and the resulting incorrect handling of resources.
We use a custom global scope provider to resolve cross references. The reference A.b looks like this when serialized:
b = "platform:/resource/someproject/somefolder/someB.b"
Likewise, the opposite looks like this:
a = ("platform:/resource/someproject/somefolder/someA.a", "platform:/resource/otherproject/otherfolder/someOtherA.a")
We know and make sure that all files only contain one object, so we omit the URI fragment. In the scope provider, a custom IEObjectDescription is constructed which uses this URI as a qualified name and silently appends the fragment "/" to it to get the real EObject URI. The mistake was in our getEObjectOrProxy() method of the IEObjectDescription, where a new resource set was created and the object was loaded into this every time. This lead to the construction of multiple ResourceSets, each with the resolved proxy, but not knowing the other side because it was in another ResourceSet, causing the infinite resolving of new "garbage" objects.
I changed the IEObjectDescription so the getEObjectOrProxy() method only outputs a proxy pointing to the URI, as the automatic proxy resolving mechanism when doing myA.getB() resolves the whole chain recursively until it hits a non-proxy object. In this case, the ResourceSet of the myA is used for resolving instead of a new ResourceSet, and all objects are updated correctly.
|
|
|
Goto Forum:
Current Time: Sun Jul 12 14:08:15 GMT 2020
Powered by FUDForum. Page generated in 0.02003 seconds |
Search
Help
Register
Login
Home
