commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Wannheden <>
Subject Re: [JXPath] unordered node-sets
Date Wed, 19 Jan 2005 15:52:09 GMT

Dmitri Plotnikov <dmitri <at>> writes:

> You are right - I am starting to forget everything.  The node set does not 
> have to be ordered, but if I want to implement axes like "preceding" and 
> "following", I have to impose some order on the object properties.

What does this mean for JXPath?  Does the ordering only ever have to take place
in PredicateContext?

> The advice I have given in similar situations before was always the same: 
> You have at least three options:
> 1. Provide custom BeanInfo that excludes upward going links, e.g. keep the 
> link from Window to Widget, but hide the link from Widget to Window.
> 2. Create custom implementations of NodePointer and NodePointerFactory 
> (which seems to be exactly what you are doing)
> 3. (IMO, the best) avoid using JXPath for extensive searches altogether - it 
> is not designed to handle them.  It can show horrific performance, which is 
> exactly what you are observing. Systems like Xalan do much better because 
> they work with static structures that they index prior to the evaluation of 
> XPaths. Try either using specific paths like "/a/b/c" or utilize indexing 
> with IdentityManager or KeyManager; or use a custom extension function to 
> perform the search.

I will try to go with option 2 as I don't think 3 really is an option; or what
other tool would let me evaluate XPaths against Java object graphs?

I don't worry about the performance too much as the queries will be run by a
user through a GUI.  What is problematic is the fact that the call to
Iterator#hasNext(), depending on the expression and object graph, is 
potentially long running and can't be interrupted.  Long running not because
JXPath couldn't yet determine if there is a next node or not, but because it
decided to prefetch and order *all* nodes which will be returned by subsequent
calls to Iterator#next().

In my case I found that this prefetching and ordering takes place in
ChildContext#constructIterator().  This method is called by
EvalContext#hasNext(), because it determined that the nodes need to be
prefetched since the ChildContext's parent context is a DescendantContext, 
which requires child ordering (in document order).

Now I hope you can see where my problem lies and why I initially asked about 
the interpretation of XPath node-sets.  After browsing the source code I think 
I now understand why it works the way it works.  What if the ordering (forward
and backward) were entirely left up to the NodeIterators?  Would that solve the

Meanwhile, to be able to interrupt JXPath, I will implement my own NodePointer
throwing an unchecked exception to abort JXPath.  (I tried this in the
NodePointerFactory, but there the exception is caught and ignored.)



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message