Hi all,

In the course of debugging
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4905 I've collected a few
issues about the cloneIterator() codepath and am posting them here for
anyone out there to review (Morten?).

I did a quick search to see if most NodeIterators reset() the clone they
were making before returning it from cloneIterator() (in light of the fix to
#4905 I'm not sure how to determine which is incorrect):

AbsoluteIterator:        return clone.reset();
CurrentNodeListIterator: return clone.reset();
PrecedingIterator:       return clone.reset();
AncestorIterator:        return clone.reset();
NodeValueIterator:       return clone.reset();
FilteredStepIterator:    return clone.resetPosition();
FilterIterator:          return clone.reset();
MatchingIterator:        return clone;
AxisIterator:            return clone;
NodeValueIterator:       return clone.reset();
NthIterator:             return new NthIterator(....);
UnionIterator:           return clone.reset();

The following I consider suspicious on the basis that during cloning the
state of the clone's _isRestartable should be changed, not the original
object's flag:

PrecedingIterator:       this._isRestartable = false;
AncestorIterator:        this._isRestartable = false;
StepIterator:            this._isRestartable = false;
UnionIterator:           this._isRestartable = false;

The following I consider suspicious on the basis that setStartNode(int) has
a codepath that calls NodeIteratorBase.resetPosition() but reset() has no
such path. I have noticed that the absence of the call to resetPosition() in
reset() caused a cloned TypedChildrenIterator to have a different state
(namely, _position was out of sync - if it matters).

TypedChildrenIterator:   return this;
UnionIterator:           return(this);

I post these things here because they don't look right; I don't know if
there are open bugs for any of this so I didn't post bug reports. Are they
mistakes? Should I submit the patches?

Cheers,

john

Reply via email to