commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <jdca...@commonjava.org>
Subject Re: [JXPATH] Am I doing something stupid here?
Date Fri, 25 Apr 2014 18:28:53 GMT

On 04/25/2014 12:42 PM, Matt Benson wrote:
> 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.

Okay, so I need to read the docs more thoroughly. :)

Thanks for the help!

>
> Matt
>
>
> On Fri, Apr 25, 2014 at 12:39 PM, John Casey <jdcasey@commonjava.org 
> <mailto:jdcasey@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 <jdcasey@apache.org
>>     <mailto:jdcasey@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-unsubscribe@commons.apache.org
>>         <mailto:user-unsubscribe@commons.apache.org>
>>         For additional commands, e-mail: user-help@commons.apache.org
>>         <mailto:user-help@commons.apache.org>
>>
>>
>
>     -- 
>     John Casey
>     ---
>     GitHub:https://github.com/jdcasey/
>     Twitter:http://twitter.com/buildchimp
>
>

-- 
John Casey
---
GitHub:  https://github.com/jdcasey/
Twitter: http://twitter.com/buildchimp


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message