Bugzilla – Full Text Bug Listing
| Summary: | erroneous "Cyclic resolution of lazy links" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Henrik Rentz-Reichert <hrr> | ||||
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | chanskw, sebastian.zarnekow, sven.efftinge | ||||
| Version: | 2.0.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Henrik Rentz-Reichert
Please check whether your qualified name computation relies on resolved links. I've slightly changed my qualified name computation for refined states by additionally testing !base.eIsProxy()
public QualifiedName qualifiedName(RefinedState rs) {
QualifiedName fqn = QualifiedName.create();
BaseState base = rs.getBase();
if (base!=null && !base.eIsProxy())
{
fqn = QualifiedName.create(base.getName());
EObject parent = base.eContainer();
while (parent instanceof BaseState) {
fqn = QualifiedName.create(((BaseState)parent).getName()).append(fqn);
parent = parent.eContainer();
}
}
return fqn;
}
But this didn't change the problem. The code is not even hit during reproduction and a complete removal of this method also didn't change the behavior.
If rs.getBase() tries to resolve a proxy, you'll end up with a cylcic resolution. Are you sure that the offending line is not hit? (In reply to comment #3) > If rs.getBase() tries to resolve a proxy, you'll end up with a cylcic > resolution. Are you sure that the offending line is not hit? Oops, you are right, it is hit. I had the breakpoint in the line following that. But - how can I avoid this problem? I never saw that in Xtext 1.0.1. Should I surround that with a try/catch? - even for a valid model I encounter this cyclic reference: the qualified name provider tries to resolve the base of the RefinedState. This calls the scope provider which resolves the actor classes base class. During the resolution of this proxy the cycle is detected. This is the simple most model to reproduce (by invoking validation): RoomModel test { ActorClass Base { Behavior { StateMachine { State sBase {} } } } ActorClass Derived extends Base { Behavior { StateMachine { RefinedState sBase {} } } } } It is usually not a good idea to rely on cross reference resolution within the qualified name provider. Is that really necessary? In Xtext 2.0 the code which throws the CyclicResolutionException has been put into a template method so you could override it try to handle this case differently. But the real source of the problems is that the qualified name provider relies on resolving cross references. Sorry, that we cannot do much about it. Thanks Sven, I think I can drop the qualified name computation for the RefinedState and ensure to have no duplicate names by validation. So far that seems to work. However, why was this no problem in Xtext 1.0.1? I really haven't understood where in my example should be a cycle... -Henrik (In reply to comment #5) > It is usually not a good idea to rely on cross reference resolution within the > qualified name provider. > Is that really necessary? > > In Xtext 2.0 the code which throws the CyclicResolutionException has been put > into a template method so you could override it try to handle this case > differently. But the real source of the problems is that the qualified name > provider relies on resolving cross references. > > Sorry, that we cannot do much about it. (In reply to comment #6) > However, why was this no problem in Xtext 1.0.1? I should have been a problem with Xtext 1.0 as well. > I really haven't understood where in my example should be a cycle... The problem is that the scope provider uses the ResourceDescriptionManager to compute the IEObjectDescription. If you resolve cross references during computation of IEObjectDescription (qualified name provider is used internally) the computation itself needs scoping. That again needs IEObjectDescriptions, etc.... bang. (In reply to comment #7) > (In reply to comment #6) > > However, why was this no problem in Xtext 1.0.1? > > I should have been a problem with Xtext 1.0 as well. No, definitely not! The following example validates perfectly using Xtext 1.0.1 using the above mentioned qualified name provider. No duplicate name errors and valid cross references. Btw: the qualified name provider is called exactly once per RefinedState during validation (e.g. when the model changes) and the cross references already are resolved at the time of invocation. On the other hand in Xtext 2.0 the cross references are not (yet) resolved when the qualified name provider is invoked. org.eclipse.xtext.resource.impl.DefaultResourceDescription.computeExportedObjects() RoomModel inherit { ActorClass Base { Behavior { StateMachine { State base0 State base1 { subgraph { State nested } } } } } ActorClass Derived extends Base { Behavior { StateMachine { RefinedState base0 { subgraph { State added State also_added } } RefinedState base1 { subgraph { State added } } RefinedState base1.nested { subgraph { State added } } } } } } I should have mentioned that in Xtext 2.0 without the qualified name provider for refined states the reference in RefinedState base1.nested can not be resolved - even though content assist proposed and inserted it. I wouldn't insist on this point if I came along without that. But I realized that I don't know how I can solve the problems described in this and the last comment. Please see also my post http://www.eclipse.org/forums/index.php?t=msg&th=207306&start=0&S=0fae87a01ef3645ea840e9b722d7b204 I've responded to the mentioned newsgroup thread. |