Pointer is an interface that is considered part of the public API. Very possibly the intent could have been more elegantly expressed by using the NodePointer API, but this *would* be a case of relying on an implementation detail, as NodePointer is the Pointer implementation used by JXPathContextReferenceImpl.
Matt On Fri, Apr 25, 2014 at 12:39 PM, John Casey <[email protected]> wrote: > 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]> 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] >> For additional commands, e-mail: [email protected] >> > > > -- > John Casey > --- > GitHub: https://github.com/jdcasey/ > Twitter: http://twitter.com/buildchimp > >
