2010/12/22 Jeremy Boynes <jboy...@apache.org> > On Dec 21, 2010, at 10:28 PM, Rex Wang wrote: > > > 2010/12/22 Jeremy Boynes <jboy...@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
