[taglibs] Refactoring XPath support

[Jeremy Boynes <jb...@apache.org>]

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 <jb...@apache.org>
>>> 
>>> 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.
> 
> 
>