I've added two attachments to bug 27717
https://issues.apache.org/bugzilla/show_bug.cgi?id=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 <jboy...@apache.org> 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
>> <c:forEach>)
>> * 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:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=22765
>> 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 future.
>>
>> 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: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
