I've been looking at this issue for a few days and I have become reasonably convinced that this is a bug in Jaxen dealing with the context node when the context node is neither the Document nor the root element in the document -- or, perhaps, when the context node was returned by a previous XPath expression.
The problem is that XPath fails to match on the context node under these
circumstances. I've written a program that demonstrates the behavior using
nothing but dom4j (dom4j-patched-1.3).
The program has two version of the same XML document built into it:
'theXML1' and 'theXML2'. The only difference between those two versions
are that one uses the default namespace where the other uses explicit
namespaces prefixes. Both versions of the XML document demonstrate the
problem:
The program accepts zero or more XPath expression on the command line. The
first XPath expression is applied to the Document. Subsequent XPath
expressions are applied to the result of the previous XPath expression. If
the result is a node-set, then the first member of that node set is used for
the subsequent test.
If you compile and run the program using the inputs specified below, the
first XPath:
'//[EMAIL PROTECTED]:href]'
will select all XLink elements in the XML document.
The second XPath:
'ibis:positionRef'
_SHOULD_ match on the <ibis:positionRef> XLink, but that match is failing,
which is the problem.
------------------
To compile:
javac -classpath WEB-INF/lib/dom4j-full.jar XPathContextNodeBug.java
To run:
java -classpath WEB-INF/lib/dom4j-full.jar\;. XPathContextNodeBug \
'//[EMAIL PROTECTED]:href]' \
'ibis:positionRef'
Thanks,
-bryan
[EMAIL PROTECTED]
XPathContextNodeBug.java
Description: Binary data
