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

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

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

Mon, 15 October 2018 14:19

Eclipse User

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 14:23] by Moderator

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

Mon, 15 October 2018 14:26

Eclipse User

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

[Updated on: Mon, 15 October 2018 14:28] by Moderator

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

Mon, 15 October 2018 14:51

Eclipse User

> 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?

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

Mon, 15 October 2018 14:57

Eclipse User

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

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

Mon, 15 October 2018 15:46

Eclipse User

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)

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

Mon, 15 October 2018 15:58

Eclipse User

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

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

Mon, 15 October 2018 16:03

Eclipse User

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?

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

Mon, 15 October 2018 19:16

Eclipse User

> 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.

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

Tue, 16 October 2018 01:07

Eclipse User

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

[Updated on: Tue, 16 October 2018 01:08] by Moderator

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

Wed, 17 October 2018 14:02

Eclipse User

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

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

Thu, 25 October 2018 10:47

Eclipse User

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?

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

Wed, 31 October 2018 11:22

Eclipse User

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.

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 [=-

Current Time: Fri Jun 20 07:48:07 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter