tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: DO NOT REPLY [Bug 50462] xalan import should not be optional in maven-bundle-plugin
Date Wed, 22 Dec 2010 09:01:57 GMT
2010/12/22 Jeremy Boynes <jboynes@apache.org>

> On Dec 21, 2010, at 10:28 PM, Rex Wang wrote:
>
> > 2010/12/22 Jeremy Boynes <jboynes@apache.org>
> >>
> >> 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:
> >
> http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.commons-jxpath
> ,
> > But that is not the least version 1.3.
>
> The official one is at:
> http://repo2.maven.org/maven2/commons-jxpath/commons-jxpath/1.3/
>
> Not sure if it's an OSGi bundle though.
>
I just saw it. Yes, it is a bundle. But seems made 2 years ago. Is jxpath
actively maintained now?

Is that what ServiceMix is doing when repackaging?
>
Yes.


>  >
> >
> >>
> >> 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 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.


And,  the performance issue is not a blocker to you to do release?

Thanks
-Rex


> --
> Jeremy
>
>


-- 
Lei Wang (Rex)
rwonly AT apache.org

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