java - Saxon-HE 9.3 的 javax.xml.xpath.XPathFactory 提供程序配置文件中的语法错误

Question

我在 Mac OS X 和 Saxon-HE 9.3.0.5 上使用 Java SE 6。 ServiceLoader 无法找到 javax.xml.xpath.XPathFactory 的 Saxon 实现。

mac:test2 ludo$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)

javax.xml.xpath.XPathFactory 的 newInstance 方法的 javadoc 在查找过程的第 3 点中声明本地化实现:

The class loader is asked for service provider provider-configuration files matching javax.xml.xpath.XPathFactory in the resource directory META-INF/services. See the JAR File Specification for file format and parsing rules.

Service Provider section JAR 文件规范声明:

The file should contain a newline-separated list of unique concrete provider-class names.

但是如果我提取 saxon9he.jar 文件并查看 META-INF 目录，我会看到:

mac:Java ludo$ mkdir test
mac:Java ludo$ cd test
mac:test ludo$ jar fx ../saxon9he.jar 
mac:test ludo$ cat META-INF/services/javax.xml.xpath.XPathFactory 
net.sf.saxon.xpath.XPathFactoryImpl
http\://java.sun.com/jaxp/xpath/dom:    net.sf.saxon.xpath.XPathFactoryImpl
http\://saxon.sf.net/jaxp/xpath/om:     net.sf.saxon.xpath.XPathFactoryImpl

第一行是正确的，但我不明白为什么有两行额外的行，看起来这些行给 ServiceLoader 带来了麻烦。我看到了我编写的一个测试示例的问题，以了解用于查找提供者的机制。我们可以看到saxon9he.jar在CLASSPATH中。

mac:services ludo$ java ServicesTest
CLASSPATH = ..., /Users/ludo/Library/Java/saxon9he.jar, ...
Service XPathFactory: java.util.ServiceLoader[javax.xml.xpath.XPathFactory]
ServiceConfigurationError: javax.xml.xpath.XPathFactory: jar:file:/Users/ludo/Library/Java/saxon9he.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: Illegal configuration-file syntax

兴趣线是:

jar:file:/Users/ludo/Library/Java/saxon9he.jar!/META-INF/services/javax.xml.xpath.XPathFactory:2: Illegal configuration-file syntax

这是 Saxon 的错误还是我的系统不支持的扩展语法？我能做些什么来解决这个问题？

请注意，如果我明确选择用于实现的类，我可以获得一个工厂。但是我想使用服务机制。以下代码有效:

XPathFactory xpf = XPathFactory.newInstance(
  XPathFactory.DEFAULT_OBJECT_MODEL_URI,
  "net.sf.saxon.xpath.XPathFactoryImpl",
  ClassLoader.getSystemClassLoader());

我在下面添加了整个 Java 测试程序。

import java.net.URL;
import java.net.URLClassLoader;
import java.util.Iterator;
import java.util.ServiceConfigurationError;
import java.util.ServiceLoader;
import javax.xml.xpath.XPathFactory;

public class ServicesTest {
    public static String getClasspathString() {
        StringBuilder classpath = new StringBuilder();
        ClassLoader classLoader = ClassLoader.getSystemClassLoader();
        URL[] urls = ((URLClassLoader) classLoader).getURLs();
        for (int i = 0; i < urls.length - 1; i++) {
            classpath.append(urls[i].getFile()).append(", ");
        }
        if (urls.length > 0) {
            classpath.append(urls[urls.length - 1].getFile());
        }

        return classpath.toString();
    }

    public static void availableProviders(ServiceLoader sl) {
        Iterator it = sl.iterator();
        int index = 0;
        for (;;) {
            try {
                if (!it.hasNext()) {
                    break;
                }
                index++;
                Object o = it.next();
                System.out.printf("%03d Concrete class name: %s\n", index, o.getClass().getName());
            } catch (ServiceConfigurationError e) {
                System.err.printf("ServiceConfigurationError: %s\n", e.getMessage());
            }
        }
    }

    public static void main(String[] args) {
        System.out.printf("CLASSPATH = %s\n", getClasspathString());
        System.out.println();

        ServiceLoader<XPathFactory> slXPathFactory = ServiceLoader.load(XPathFactory.class);
        System.out.printf("Service XPathFactory: %s\n", slXPathFactory.toString());
        availableProviders(slXPathFactory);
    }
}

Answer 1

迈克尔·凯 answered the question在 SourceForge 论坛上。他说:

The format of the file was chosen to circumvent a JDK5 bug.

还有:

Actually, I wouldn't recommend using the JAXP search mechanism anyway. It's very slow, and it delivers an XPath engine that won't necessarily work with your application. You have no way of knowing whether you get an XPath 1.0 or 2.0 implementation back, and the API is so weakly defined that there's very little chance your application will work with a particular provider unless you have tested it with that provider first. So even without this bug, I would steer clear of it.

我认为它回答了问题，即使它没有为问题提供明确的解决方案。所以我们可以通过编写来选择实现:

XPathFactory xpf = XPathFactory.newInstance(
  XPathFactory.DEFAULT_OBJECT_MODEL_URI,
  "net.sf.saxon.xpath.XPathFactoryImpl",
  ClassLoader.getSystemClassLoader());