|
I can reproduce this with a slightly simpler document:
<body><p><span></span></p><div></div></body> In code (for XOM): I'm still trying to work through this one, but I think the problem is in StackedIterator, and I think this affects some other bugs as well. Specifically I think stacking the iterators is producing a breadth-first search when we need to be using a depth-first search instead.
I don't think its the stacked iterator, I think its the use of 'ChildAxisIterator' in that stack.
The correct logic for PrecedingAxis is roughly this: public boolean hasNext() { public Object next() { initializing this with empty iterators for descendantOrSelfReversed and precedingSibling. The current implementation looks to me like its not reversing descendantOrSelf, but is reversing the order in which the children are accessed on that axis. after some headscratching I wrote this: its self contained so its simpler to see that it is correct. It passes the tests for everything but dom4j, because, as far as I can tell, that navigator reports parent(Document) as Document, not null. Leaving this for others to see in case I can't figure it out but I think its worth committing.
Elliotte, I've updated the code for the preceding, ancestor, and descendant axes, but added the test you described above for this bug afterwards. It passes, but I'd prefer if you can confirm and close this bug by just updating your 'xml' directory first? Its the very first test that runs (see top of tests.xml), I'd expect you to get later test failures for Docment node stringvalues etc.
Yes, Brian's latest patches appear to fix this (among other issues).
Tonight I got this bug back again...with the DOM navigator. It seems the bug is intermittent and it may depend on something odd like object identities as hash keys. Commenting out the code overriding the 'preceding' axis in the DOM so it gets the new version appears to resolve the problem, but I'll need to walk the DOM code to be sure its wrong.
yep... the DOM code was wrong. Not sure why this didn't show up yesterday. Fixed.
Hmm, this seems to have resurfaced in the DOM navigator. Will investigate further.
I think I've got this fixed. The problem was in dom.DocumentNavigator's custom PrecedingAxisIterator. For the moment I've disabled this so a correct implementation is inherited from the superclass instead. Whether it makes sense to fix that or leave it as is remains to be seen, so I'll leave this one for now in case someone wants to revisit that.
|
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
preceding axis fails to report reverse document order
JAXEN-21, but it isn't..JAXEN-21is actually misreported.Here is some code that reproduces this issue:
import java.io.StringReader;
import java.util.Iterator;
import java.util.List;
import org.jaxen.jdom.JDOMXPath;
import org.jdom.Document;
import org.jdom.input.SAXBuilder;
import org.jdom.output.XMLOutputter;
public class TestJ {
public static void main(String[] args) throws Exception { XMLOutputter outputter = new XMLOutputter(); SAXBuilder builder = new SAXBuilder(); Document doc = builder.build( new StringReader( new String("<html><head> </head> <body> <p> <span> text1 </span> </p> <div> text2 </div> </body> </html>"))); JDOMXPath query = new JDOMXPath("//div/preceding::*"); List set = query.selectNodes(doc); for (Iterator iter=set.iterator();iter.hasNext();) System.out.println(iter.next()); outputter.output(set, System.out); }
}