tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: [taglibs] XPath support
Date Mon, 12 Jul 2010 05:40:39 GMT
Implementation seems to work but does not provide as much benefit as expected. Jasper tag pooling
does not pool tags with the same attribute values so the select attribute is set every time
causing recompilation. The time taken to iterate 1000 <x:out> tags drops from around
2800ms to 1800ms.

To work around this I added a thread-local cache of compiled XPath expressions. This does
reduce the initial time taken for the first few iterations but the time taken to evaluate
the compiled expression grows from 500us to 2100us toward the end of the loop (measured with
nanoTime() around the call to evaluate). There may be some issue with Xalan; the same behaviour
is seen with Sun's JAXP implementation included in JDK1.6 (which is based on Xalan).

The same slowdown is seen if the expression is evaluated each time, or if the xpath is run
in a standalone testcase outside taglibs entirely. There may be an issue here with Xalan and/or
the JDK.

We might be advised to consider a different XPath implementation. Does anyone have any thoughts
on Jaxen?


On Jul 10, 2010, at 10:38 PM, Jeremy Boynes wrote:

> I've added two attachments to bug 27717
> that show ExprSupport updated to use the JAXP XPath API to precompile expressions and
an implementation of an XPathVariableResolver that handles the JSTL variable resolution scheme.
> There are very few tests for the XML tags so I want to add more to check for regressions
and that may take a while. Comments on the approach would be appreciated before I start on
the other tags. I'll post some performance numbers once I've updated <x:forEach>
> Cheers
> Jeremy
> On Jul 9, 2010, at 9:56 PM, Henri Yandell wrote:
>> On Fri, Jul 9, 2010 at 12:51 PM, Jeremy Boynes <> wrote:
>>> In light of the performance issues logged against the XML taglib and functional
issues like #49578, I was looking at refactor the XML tags to use the JAXP XPath API to pre-compile
expressions and dynamically resolve variables. I think this can be done fairly easily and
will eliminate a lot of the integration code in XPathUtil. However, I could not see how to
expose the full iteration context described in the spec for <x:forEach>:
>>> * the context position is the iteration 'count' (with the same meaning as in
>>> * the context size is equal to the number of nodes in the node-set over which
<x:forEach> is iterating
>>> It looks like the current implementation does not support this:
>>> and in testing these functions always return -1 and 0 respectively.
>>> Presumably these should be returned by the XPath core functions position() and
last() respectively. However, the JAXP API only allows a single Node to be passed in for evaluation
and I could not see a way to provide the context needed by these functions. I think this might
be a limitation of JAXP.
>>> I plan to go ahead with the refactor as I think by simplifying our implementation
we will address the current performance issues and fix some of the functional edge cases.
It will also remove the hard dependency on the Xalan implementation.The iteration context
functions will remain broken consistent with the current implementation.
>>> It might be possible to make this work using the low-level internal Xalan APIs
as this functionality is supported in Xalan's XSLT processing. To support this in the future,
I'll try to make the XPath usage pluggable so we can drop in a Xalan-specific version in the
>>> Thoughts?
>> +1. Resolving the speed and some of the issues is worth making it
>> harder to resolve the other issues imo.
>> Hen
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message