Re: [JXPATH] Am I doing something stupid here?
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 <mailto: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 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: org.group artifact-id 2.6 declared by project with groupId 'org.test' Does this help? Matt On Mon, Apr 14, 2014 at 1:09 PM, John Casey mailto: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...@common
Re: [JXPATH] Am I doing something stupid here?
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 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: org.group artifact-id 2.6 declared by project with groupId 'org.test' Does this help? Matt On Mon, Apr 14, 2014 at 1:09 PM, John Casey <mailto: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 <mailto:user-unsubscr...@commons.apache.org> For additional commands, e-mail: user-h...@commons.apache.org <mailto:user-h...@commons.apache.org> -- John Casey --- GitHub: https://github.com/jdcasey/ Twitter: http://twitter.com/buildchimp
[JXPATH] Am I doing something stupid here?
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 http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> 4.0.0 org.test test-project 1.0 org.group artifact-id 2.6 package org.commonjava.maven.galley.maven.model.view; import java.io.InputStream; import java.io.StringWriter; import java.util.List; import java.util.Stack; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.transform.OutputKeys; import javax.xml.transform.Transformer; import javax.xml.transform.TransformerFactory; import javax.xml.transform.dom.DOMSource; import javax.xml.transform.stream.StreamResult; import org.apache.commons.jxpath.JXPathContext; import org.junit.Before; import org.junit.Test; import org.w3c.dom.Document; import org.w3c.dom.Node; public class JXPathContextAncestryTest { @Test public void basicJXPathTest() 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 ); document.getDocumentElement() .removeAttribute( "xmlns" ); final String projectGroupIdPath = "ancestor::project/groupId"; // NOT what's failing...just populating the node set to traverse in order to feed the ancestor:: axis test. final List nodes = ctx.selectNodes( "/project/dependencies/dependency" ); for ( final Object object : nodes ) { final Node node = (Node) object; dump( node ); final Stack revPath = new Stack(); Node parent = node; while ( parent != null ) { revPath.push( parent ); parent = parent.getParentNode(); } JXPathContext nodeCtx = null; while ( !revPath.isEmpty() ) { final Node part = revPath.pop(); if ( nodeCtx == null ) { nodeCtx = JXPathContext.newContext( part ); } else { nodeCtx = JXPathContext.newContext( nodeCtx, part ); } } System.out.println( "Path derived from context: '" + nodeCtx.getNamespaceContextPointer() .asPath() + "'" ); // brute-force approach...try to force population of the parent pointers by painstakingly constructing contexts for all intermediate nodes. System.out.println( "Selecting groupId for declaring project using path-derived context..." ); System.out.println( nodeCtx.getValue( projectGroupIdPath ) ); // Naive approach...this has all the context info it needs to get parent co