Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346178

Summary: LazyLinkingResource.getEObject fails on unresolved proxy object
Product: [Modeling] TMF Reporter: Peter Feiler <phf>
Component: XtextAssignee: Project Inbox <tmf.xtext-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: critical    
Priority: P3 CC: sebastian.zarnekow
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Contains simplified problem grammar, example model and stack traces none

Description Peter Feiler CLA 2011-05-17 21:05:57 EDT 
Build Identifier: 20110218-0911

The Triple.add call in  LazyLinkingResource.getEObject fails on an unresolved proxy object (reference to Greeting in GreetingValue) and recurses on equals.  

My grammar is based on an existing Ecore Meta model. I have recreated a minimal grammar that can reproduce the problem.

In my original grammar one of the classes (GreetingValue in the grammar below) has the equals method overridden as shown in the attachment. 

When I open the example model file Xtext recurses infinitely trying to resolve a reference proxy that is not resolvable. I am showing the recursive stack trace as well as the stack when stepping through to the first time it encounters a problem and starts recursing. 

This problem does not occur when I do not include the equals method.

See attachment for the grammar, example model, and equals method.

Reproducible: Always

Steps to Reproduce:
1. Generate editor from grammar
2. Add equals method to GrammarValueImpl
3. Open example model file
Comment 1 Peter Feiler CLA 2011-05-17 21:11:31 EDT 
Created attachment 195933 [details]
Contains simplified problem grammar, example model and stack traces
Comment 2 Sebastian Zarnekow CLA 2011-05-18 01:07:04 EDT 
Hi Peter,

thanks for the detailled report. Are you aware of the fact that EObjects may not specify equals and hashcode? See Javadoc of EObject: "The framework also assumes that implementations will not specialize {@link #equals(Object)} (nor {@link #hashCode()})
so that "<code>==</code>" can be always used for equality testing;"

Therefore I close this one as won't fix. Please reopen if I missed something.
Comment 3 Peter Feiler CLA 2011-05-18 11:27:31 EDT 
(In reply to comment #2)
> Hi Peter,
> 
> thanks for the detailled report. Are you aware of the fact that EObjects may
> not specify equals and hashcode? See Javadoc of EObject: "The framework also
> assumes that implementations will not specialize {@link #equals(Object)} (nor
> {@link #hashCode()})
> so that "<code>==</code>" can be always used for equality testing;"
> 
> Therefore I close this one as won't fix. Please reopen if I missed something.

Thanks for the clue.  I had missed that.
Comment 4 Karsten Thoms CLA 2017-09-19 17:41:42 EDT 
Closing all bugs that were set to RESOLVED before Neon.0
Comment 5 Karsten Thoms CLA 2017-09-19 17:52:50 EDT 
Closing all bugs that were set to RESOLVED before Neon.0