tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject [taglibs] Refactoring XPath support
Date Fri, 31 Dec 2010 03:23:17 GMT
I've added a patch to #27717 that changes the XML tags to use Xalan's low-level API directly.
This addresses:
1) Most of the performance issues with iteration from #27717
2) Support for position() and last() from #22765 and others
3) Support for using the same variable twice from #49578
which basically clears up the open bugs with the XML taglib

On my machine, iterating 100000 items took 1600ms which seems OK. It still increases with
n^2 for some reason I have not figured out.

On Dec 22, 2010, at 7:47 PM, Jeremy Boynes wrote:

> On Dec 22, 2010, at 1:01 AM, Rex Wang wrote:
>> 2010/12/22 Jeremy Boynes <>
>>> The XPath implementation in Oracle's JDK was originally based on Xalan and
>>> has the same performance issue.
>>> One issue with the JAXP API is that it does not allow context to be passed
>>> to the evaluation and so the XPath position() and last() functions can't be
>>> supported (at least, I've not figured out how). Now the current
>>> implementation does not support them either (see #22765) so this may not be
>>> a major issue, but the proprietary APIs in Jaxen and JXPath should enable
>>> this (would need to code it to be sure).
>>> How about:
>>> * define our own API that allows context to be passed
>>> * create a context-free wrapper for JAXP and remove the hard dependency on
>>> Xalan (solving the optional bundle issue)
>>> * create other wrappers for Jaxen and/or JXPath that can use the context
>>> We could proceed with a release based on the first two steps alone as
>>> there's no regression.
>> +0 if the reason of defining our own api is only to resolve #22765, since it
>> is not required by spec.
> Reading the last 2 bullets on pp157 it references context position and size and the only
way to access those in XPath would be using the position() and last() functions.
>> And,  the performance issue is not a blocker to you to do release?
> It's been there long enough so no :)
> It's more that if a fix requires changes to the dependencies it's user impacting.
> There are still the two issues with the fmt library and 50265 is functionally broken
not just a performance issue.

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