[news.eclipse.tools.emf] Re: TraversalStrategy's double visits

["John J. Franey" <jjfraney@xxxxxxxxx>]

On Thu, 17 Sep 2009 09:33:10 -0400, Christian W. Damus wrote:

> Hi, John,
> 
> Are you certain that the validator is not actually being invoked twice?
> The default recursive strategy takes steps to ensure that, if it is
> invoked on a collection of objects, it doesn't re-visit elements that
> are contained in (and thus traversed recursively from) other elements
> also in the selection set from which it starts.
> 
I'm quite certain.

It looks like org.eclipse.emf.common.util.AbstractTreeIterator (ATI) 
manages a stack for the recursion, if I am making this out correctly.  
Apparently, its 'data' field is used as a stack.  When a call to 
getChildren returns an iterator with stuff to iterate, ATI puts the 
iterator on the stack and subsequent calls to next will pull from that 
iterator.  When that iterator is spent, it is popped from the stack and 
ATI will run a next on the earlier iterator.  Do I have that right?

So, with the input I provided, the first call to ATI.next ought to return 
a 'component' eobject.  On entrance to this first call, the only  element 
on the 'data' stack is ITraversalStrategy$Recursive object.  During this 
call, getChildren on the 'component' eobject returns a EContentsEList
$FeatureIterator object and ATI pushes that on the 'data' stack.  Later 
calls to ATI pulls from that new iterator and that returns four eObjects 
in this sequence: 'implementation', 'service', 'implementation', 
'service'.


I single step through hasNext and next methods of EContentsElist
$FeatureIterator.

Here is the iterator's value of eStructuralFeatures array whose length 
is 4:

org.eclipse.emf.ecore.impl.EAttributeImpl@61328229 (name: mixed) 
(ordered: true, unique: false, lowerBound: 0, upperBound: -1) 
(changeable: true, volatile: false, transient: false, 
defaultValueLiteral: null, unsettable: false, derived: false) (iD: false)

org.eclipse.emf.ecore.impl.EReferenceImpl@26b056fd (name: implementation) 
(ordered: true, unique: true, lowerBound: 1, upperBound: 1) (changeable: 
true, volatile: true, transient: true, defaultValueLiteral: null, 
unsettable: false, derived: false) (containment: true, resolveProxies: 
false)

org.eclipse.emf.ecore.impl.EReferenceImpl@2a8e32b7 (name: service) 
(ordered: true, unique: true, lowerBound: 0, upperBound: 1) (changeable: 
true, volatile: true, transient: true, defaultValueLiteral: null, 
unsettable: false, derived: false) (containment: true, resolveProxies: 
false)

org.eclipse.emf.ecore.impl.EReferenceImpl@3aff8399 (name: reference) 
(ordered: true, unique: true, lowerBound: 0, upperBound: -1) (changeable: 
true, volatile: true, transient: true, defaultValueLiteral: null, 
unsettable: false, derived: false) (containment: true, resolveProxies: 
false)

It looks like the iterator retrieves the first 'implementation' and 
'service' eObjects as result of interpreting the first element in 
eStructuralFeatures.  The second 'implementation' comes from interpreting 
the second element of eStructuralFeatures.  The second 'service' comes 
from interpreting the third element of eStructuralFeatures.  I can give 
details of this debugging session.  Its painstaking.  I hope I don't have 
to do it.


So the question: is the iterator being initialized incorrectly (incorrect 
content of eStructuralFeatures), or does it interpret eStructuralFeatures 
incorrectly?



> I can't think of a means by which the default traversal strategy would
> visit these elements twice.  The containment of your objects is very
> simple.
> 
> If you put a breakpoint in the DefaultTraversalStrategy (I hope that's
> the name) then you should be able to infer from the call stack the
> reason for the repeated visit.
> 
> HTH,
> 
> Christian
> 
> 
> On Wed, 2009-09-16 at 19:25 +0000, John J. Franey wrote:
> 
>> I have a situation where the BatchValidator is visiting some eobjects
>> twice.  I've been in debugging session for a few hours and am not
>> seeing what factor would lead to this.
>> 
>> Here is the model serialized as xml:
>> 
>> <?xml version="1.0" encoding="UTF-8"?> <scr:component
>>   xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"; enabled="true"
>>   factory="" immediate="false" name="Command Provider for Dictionary
>>   Service" activate=""
>>   deactivate=""
>>   modified="">
>>      <implementation class="jjjjjjjjjj"/>
>>      <service/>
>> </scr:component>
>> 
>> 
>> This is the order the strategy returns:
>> 
>> component -> implementation -> service -> implementation -> service.
>> 
>> If a single constraint is defined for 'implementation', it run twice.
>> Two IStatus are returned indicating the same constraint failure on the
>> same eobject. They have the same message, as do the two markers that
>> are consequently created by BatchValidator.
>> 
>> What can I do so these are visited only once?
>> 


Thanks for looking at this.
John