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 <jdca...@commonjava.org> 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 <jdca...@apache.org> 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: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>
>
> --
> John Casey
> ---
> GitHub: https://github.com/jdcasey/
> Twitter: http://twitter.com/buildchimp
>
>
