tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
Date Wed, 22 Dec 2010 07:45:00 GMT
On Dec 21, 2010, at 10:28 PM, Rex Wang wrote:

> 2010/12/22 Jeremy Boynes <>
>> Perhaps the changes needed to address the performance issue in #27717 are
>> relevant here.
>> These stem from issues in Xalan's implementation which would also apply if
>> we tried to use the JDK's implementation. I had a prototype working with
>> Jaxen but the project is pushing builds to the Maven repos and does not seem
>> very active (like, no-one replied to a recent committer call) so depending
>> on it could be problematic. I was thinking of using JXPath instead (from
>> commons).
> I also don't find JXPATH in maven repo.. However, you also can use the
> servicemix bundled one:
> But that is not the least version 1.3.

The official one is at:

Not sure if it's an OSGi bundle though. Is that what ServiceMix is doing when repackaging?

>> With multiple options out there, perhaps we could just have taglibs use an
>> interface and provide wrappers for each as separate modules. if we did that,
>> is that something that could be easily handled with OSGi?
> I am not very familiar with XPATH. Do you mean the approach like spi?
> IIUC, xalan implements the spi of javax.xml.transform.TransformerFactory and
> javax.xml.xpath.XPathFactory. So if xalan is in the path, we can choose it
> as the xpath implementation. I am not sure if jaxen and jxpath implement the
> spi either.
> Why not move to the standard api in jdk instead of defining new apis and
> wrappers?

The XPath implementation in Oracle's JDK was originally based on Xalan and has the same performance

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.


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