Yep, that makes a certain kind of sense, though I guess I wouldn't
exactly call it intuitive. I can see how creating a new context each
time could be a bad idea (and very inefficient, I suspect)...though it
seems (to a newbie anyway) that the pointers are an implementation
detail that leak out in this case.
Or, maybe I just haven't read enough of the docs?
At any rate, thanks for your reply. Maybe once this project I'm working
on is done, I'll take a look at modernizing JXPath. It does seem faster
than the built-in JAXP stuff.
-john
On 04/25/2014 12:33 PM, Matt Benson wrote:
Hi, John. Sorry for the long delay.
The original authors of JXPath are long gone, but from what I can
reconstruct the intent of nested JXPathContexts is only to unify
treatment of things like variables, namespaces, and at a guess,
functions. AFAICT your test case appears to have overcomplicated the
issue, although notably my alternative does resort to some string
concatentation to accomplish the same apparent purpose of the test
case. Certainly the whole JXPath codebase could benefit from some
modernization. In any event, I have:
@Test
public void anotherTest() throws Exception {
final InputStream is =
Thread.currentThread().getContextClassLoader().getResourceAsStream("jxpath/simple.pom.xml");
final Document document =
DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is);
final JXPathContext ctx = JXPathContext.newContext(document);
// not sure why this was done, but I have preserved it
document.getDocumentElement().removeAttribute("xmlns");
for (@SuppressWarnings("unchecked")
Iterator<Pointer> ptrs =
ctx.iteratePointers("/project/dependencies/dependency");
ptrs.hasNext();) {
final Pointer ptr = ptrs.next();
dump((Node) ptr.getNode());
System.out.printf("declared by project with groupId
'%s'%n", ctx.getValue(ptr.asPath() + "/ancestor::project/groupId"));
}
}
which yields output:
<dependency>
<groupId>org.group</groupId>
<artifactId>artifact-id</artifactId>
<version>2.6</version>
</dependency>
declared by project with groupId 'org.test'
Does this help?
Matt
On Mon, Apr 14, 2014 at 1:09 PM, John Casey <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
I'm trying to learn how to use JXPath with DOM in order to speed
up some code that uses a lot of xpath. I've seen blog posts
suggesting it's about twice as fast as JAXP's XPath processor...
The problem I'm running into is when I construct a JXPathContext
around a node down in the DOM tree, then try to select a node
elsewhere in the tree using the ancestor:: axis. I'm attaching a
sample XML file and unit test that shows what I'm trying to do.
I've run this through a debugger, and it appears that the
DOMNodePointer.getImmediateParent() doesn't even try to look at
the Node.getParentNode()...if it doesn't have a pre-existing
parent (from its ctor) then it just dumbly returns the null parent.
I haven't done enough research yet to know how to get
DOMNodePointer to populate its parent (using the public API, not
the nuts-and-bolts impl details), but in the attached example you
can see I try two approaches:
1. the naive approach, which is also the last one in the code.
IMO, this one should work!
2. a brute-force alternative, where JXPathContext instances for
each intermediate node are created to inherit in the right order,
all the way back to the document itself. From my partial reading
of the code, this should work even if the naive approach doesn't.
Neither of these works, though. Can someone shed some light on it,
or let me know if I've found a bug (seems like a common use case)...
Thanks,
-john
--
John Casey
GitHub - http://github.com/jdcasey
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
John Casey
---
GitHub: https://github.com/jdcasey/
Twitter: http://twitter.com/buildchimp
