Eclipse Community Forums: TMF (Xtext) » Confused: Cyclic resolution of lazy links

Help

Home

Home » Modeling » TMF (Xtext) » Confused: Cyclic resolution of lazy links

Show: Today's Messages :: Show Polls :: Message Navigator

Confused: Cyclic resolution of lazy links [message #1796526]

Mon, 15 October 2018 18:19

Brandon Lewis

Messages: 268
Registered: May 2012

Senior Member

I'm confused.

I'm getting errors with cyclic resolution of lazy links when I'm trying to access references in my DerivedStateComputer. As I'm trying to resolve my references, it does not seem "cyclic" to me as I'm just following the reference paths specified in my EMF model, so right away I'm confused on the terminology and how to resolve my issue.

Some background:

Grammar snippet:

Test returns Test:
	{Test}
	'Test' ':' name=EString
	(BEGIN
    ('description' ':' description=EString)?	
    ('attributeGroup' ':' attributeGroup=[AttributeGroup|QualifiedName])?
	END)?;

In my DerivedStateComputer while preLinkingPhase is false, the following access is triggering the error:

test.getAttributeGroup()

In my EMF code, getAttributeGroup() seems to be built to resolveProxies (it's autogenerated code), but the first time this is accessed, the error fires. It looks like subsequent getAttributeGroup() calls are able to resolve it.

The AttributeGroup object is described in a separate resource that is imported via the ImportURI mechanism - so the imported resource should be visible.

is there some "standard trick" I can use to resolve these references in my DerivedStateComputer? I've randomly tried some EcoreUtil2 methods, but I'm getting nowhere.

That's one example, but I seem to be hitting the Cyclic resolution of lazy links anytime I make a reference to an Object that is contained within another file (that is imported via the ImportURI mechanism).

[Updated on: Mon, 15 October 2018 18:23]

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796527 is a reply to message #1796526]

Mon, 15 October 2018 18:26

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

How is your scoping implemented
The error happen when you try to access a reference while you are resolving it

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

[Updated on: Mon, 15 October 2018 18:28]

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796528 is a reply to message #1796527]

Mon, 15 October 2018 18:51

Brandon Lewis

Messages: 268
Registered: May 2012

Senior Member

> How is your scoping implemented

Good question.... I might be shooting myself in the foot. I don't have scoping set to AttributeGroups, but I do have a custom scoping for what I call testPlanRef and these testPlanRefs are eventually showing up as Cyclic resolution problems.

  def scope_TestPlanInstance_testPlanRef (TestPlan tp, EReference ref) {

    val existingScope = delegateGetScope(tp, ref)
    
    // Scope that filters out the context element from the candidates list
    return new FilteringScope(existingScope, [getEObjectOrProxy != tp])
 }

Where the grammar for testPlanRef looks like: (and the referenced TestPlan is contained in an external, but imported document)

TestPlanInstance returns TestPlanInstance:
  testPlanRef=[TestPlan|EString] ':' name=EString   
;

I did this because I didn't want the code completion to allow a TestPlan to reference itself (which would result in stack overflow infinite loops). So maybe I just took my own TestPlan out of scope?

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796529 is a reply to message #1796528]

Mon, 15 October 2018 18:57

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

can you please provide the complete error message.
can you create a minimal reproducing unit test

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796532 is a reply to message #1796529]

Mon, 15 October 2018 19:46

Brandon Lewis

Messages: 268
Registered: May 2012

Senior Member

It'll take me a bit to create a standalone example:

But here is a good portion of some of the errors I'm getting. My domain is "tps"

In my code I'm instantiating some TestPlans from another file. Some of those TestPlans import another file to get Attribute groups.

So to me it looks like I'm doing "transitive" accesses and not cyclic ones, but I don't understand it so I'm sure I'm wrong:

  
imports:
    - import: "second.tps"
    - import: "fourth.tps"
    - import: "fifth.tps"
    
  testPlanInstances:
    - fourth:  iFourth
    - secondTestPlan : second

org.eclipse.xtext.linking.lazy.LazyLinkingResource$CyclicLinkingException: Cyclic resolution of lazy links : Test.attributeGroup->Test.attributeGroup in resource 'platform:/resource/TPS/second.tps'.
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.handleCyclicResolution(LazyLinkingResource.java:302)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:240)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:222)
	at org.eclipse.xtext.resource.persistence.StorageAwareResource.getEObject(StorageAwareResource.java:122)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:199)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:259)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1477)
	at tps.impl.TestImpl.getAttributeGroup(TestImpl.java:197)
	at company.com.tps.resource.TpsResource$DerivedStateComputer.expandTestAttributes(TpsResource.java:105)
	at company.com.tps.resource.TpsResource$DerivedStateComputer.installDerivedState(TpsResource.java:72)

Another one:

[main] ERROR org.eclipse.xtext.linking.lazy.LazyLinkingResource  - Cyclic resolution of lazy links : TestPlanInstance.testPlanRef->TestPlanInstance.testPlanRef in resource 'platform:/resource/TPS/fourth.tps'.
org.eclipse.xtext.linking.lazy.LazyLinkingResource$CyclicLinkingException: Cyclic resolution of lazy links : TestPlanInstance.testPlanRef->TestPlanInstance.testPlanRef in resource 'platform:/resource/TPS/fourth.tps'.
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.handleCyclicResolution(LazyLinkingResource.java:302)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:240)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:222)
	at org.eclipse.xtext.resource.persistence.StorageAwareResource.getEObject(StorageAwareResource.java:122)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:199)
	at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:259)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1477)
	at tps.impl.TestPlanInstanceImpl.getTestPlanRef(TestPlanInstanceImpl.java:163)
	at company.com.tps.resource.TpsResource$DerivedStateComputer.installDerivedState(TpsResource.java:58)
	at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:242)

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796533 is a reply to message #1796532]

Mon, 15 October 2018 19:58

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

i would need a reproducing example with unit test to debug this. the stacktraces seem to be incomplete

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796534 is a reply to message #1796533]

Mon, 15 October 2018 20:03

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

how does the hash set at point of error look like? and the current parameter?
org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(String, Triple<EObject, EReference, INode>)
(the hashset may give you hints on which "path" the problem happens

is there any reason you cannot use normal import uri/index based scoping?
why is this needed to be done in derived state computer?

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796543 is a reply to message #1796534]

Mon, 15 October 2018 23:16

Brandon Lewis

Messages: 268
Registered: May 2012

Senior Member

> The error happen when you try to access a reference while you are resolving it

Is there a general practice for avoiding the above sentence? I though EMF was supposed to handle that stuff for me in its getters with the checks for eProxy and all the resolve stuff.

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796555 is a reply to message #1796543]

Tue, 16 October 2018 05:07

Christian Dietrich

Messages: 14665
Registered: July 2009

Senior Member

Emf has no scoping. Xtext has
As I said I need a reproducing example to exactly know what goes wrong in your case

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

[Updated on: Tue, 16 October 2018 05:08]

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1796698 is a reply to message #1796555]

Wed, 17 October 2018 18:02

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

I encountered this problem a few times with OCL which has its own scope resolution. The problem is irritating, simple but reasonable and fortunately diagnosed better than a StackOverflow.

If you have a reference to e.g. A::B::C and start resolving it you will probably start a nested resolution of A::B (and worse a further nested resolution of A) => BANG.

You MUST resolve A BEFORE you START to resolve A::B, BEFORE you START to resolve C. For OCL this meant eager resolution of qualifiers.

Regards

Ed Willink

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1797119 is a reply to message #1796698]

Thu, 25 October 2018 14:47

Brandon Lewis

Messages: 268
Registered: May 2012

Senior Member

Thanks for the discussion guys. After reading each of your responses and doing several days of experiments (not full time), I can safely say this is a scoping issue and I've been seriously confused by the verbiage used in the error message.

I believe by default I'm using the ImportURIScopingFragment and importURI method (both my grammar and MWE2) (because my customers will never know where their files are coming from and most don't have experience with Eclipse). This scoping method isn't working with what I think are transitive dependencies within scope (triggered by Ed's A::B::C nomenclature).

I've been able to access and put into scope all of my top level visible objects in the index and this appears to have fixed my scoping problem - at the expense of introducing editor behavior totally unlike the intended importURI scoping expectations. (just make everything in scope and solved! :-) )

I believe, based on experiments, I need to go in this direction:

https://blogs.itemis.com/en/in-five-minutes-to-transitive-imports-within-a-dsl-with-xtext

Any thoughts on that?

Report message to a moderator

Re: Confused: Cyclic resolution of lazy links [message #1797489 is a reply to message #1797119]

Wed, 31 October 2018 15:22

Brandon Lewis

Messages: 268
Registered: May 2012

Senior Member

FWIW, the example above solved my problem. Basically the cyclic resolution of lazy links was due to a scoping problem due to transitive importURI needs. The link above did need some tweaks for me and I've sent feedback to the blog owner.

Thanks for the help in pointing me in the right direction.

Report message to a moderator

Previous Topic:	cross-reference scoping from 2 different grammar/models
Next Topic:	Change PLUGIN_ID field in generated UI activator

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 21:06:27 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter