如何防止具有 META-INF\services\javax.xml.transform.TransformerFactory 的 xalan.jar 接管 Xalan 实现中内置的 JDK 1.6？

Question

考虑一下这段代码（完全基于飞碟的“入门”代码，保留他们的权利）：

package flyingsaucerpdf;
import java.io.File;
import java.io.FileOutputStream;
import java.io.OutputStream;

import org.xhtmlrenderer.pdf.ITextRenderer;


    public class PDFMaker {
        public static void main(String[] args) throws Exception {
            new PDFMaker().go();
        }

        public void go() throws Exception {
            String inputFile = "sample.html";
            String url = new File(inputFile).toURI().toURL().toString();
            String outputFile = "firstdoc.pdf";
            OutputStream os = new FileOutputStream(outputFile);

            ITextRenderer renderer = new ITextRenderer();
            renderer.setDocument(url);
            renderer.layout();
            renderer.createPDF(os);

            os.close();
        }
    }

几个事实：

1. 使用 JDK 1.6 或 1.5 独立运行它（调用 main）可以完美地工作（生成 PDF）
2. 但是当通过 URLClassLoader 从现有的Web应用程序失败并出现以下错误：

Caused by: org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
    at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
    at org.apache.xerces.dom.AttrNSImpl.(Unknown Source)
    at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown Source)
    at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source)
    at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:307)
    ... 19 more

在错误的地方寻找了一段时间后（例如，我创建了一个怀疑xalan / xerces jar的子优先/父最后的类加载器，但它仍然失败），我终于缩小了范围根本原因：

加载我的代码的 Web 应用程序似乎有一个旧的 xalan.jar，规范版本 1.2

我做了一些测试，我将上面的代码作为独立运行（之前运行良好） ）但是这次我将 Web 应用程序中的 xalan.jar 添加到它的类路径中，宾果，与 Web 应用程序场景中的错误相同

所以我检查了旧的 xalan.jar 并想知道，可以做什么导致 JVM 加载旧的 xalan 实现而不是 JDK 的？毕竟我的子类加载器也是父类加载器最后的，例如中间的系统，也就是说：在父类加载器之前搜索系统类加载器（以避免加载父类覆盖的 JDK jar，就像父类的 xalan.jar 覆盖的情况一样） JDK 的 xalan 实现）

然后有些东西让我眼前一亮 - xalan.jar/META-INF/services/ 中名为 javax.xml.transform.TransformerFactory 的文件内容如下：

org.apache.xalan.processor.TransformerFactoryImpl

所以我立即在 Eclipse 中按 Ctrl+T 并查找完整的限定名称...仅在 xalan.jar 中！

然后我只搜索“TransformerFactoryImpl”，这就是 JDK 所具有的：

com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

很容易看出差异

所以，如果你读到这里，我的底线问题是：如何让我的 TransformerFactory 使用 JDK 的实现和不是旧的 Xalan 的吗？（我无法从要加载代码的 Web 应用程序中删除该 jar）

Answer 1

如果您正在开发 Web 应用程序，因此无法设置系统属性，那么最直接的方法是显式请求 JDK 转换器。
以下是内部 XSLTC 转换器（具有 StAXSupport）的示例。

TransformerFactory tf = TransformerFactory.newInstance(
        "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl", null);

Answer 2

您还应该注意，您根本不需要使用 SPI 机制。

您可以使用 http://download.oracle.com/javase/6/docs/api/javax/xml/xpath/XPathFactory.html#newInstance(java.lang.String, java.lang.String, java.lang. ClassLoader），一旦您知道相关类的名称，就可以在您自己的隔离类加载器中使用 xalan 的副本。

Answer 3

我正在使用 Wildfly 应用程序服务器和使用 TransformerFactory 的第 3 个 jar。

使用文件 resources\META-INF\services\javax.xml.transform.TransformerFactory 覆盖 TransformerFactory。不适合我。

当我查看 FactoryFinder 实现（JDK8u201）时。我发现以下代码片段

String systemProp = ss.getSystemProperty(factoryId);
if (systemProp != null) {
    dPrint("found system property, value=" + systemProp);
    return newInstance(type, systemProp, null, true);
}

因此，解决方案是将系统属性 javax.xml.transform.TransformerFactory 设置为 com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl。

干杯

Answer 4

看来答案比我想象的要简单。

1. 在您的类加载器中，将以下文件夹添加到类路径（不需要 jar）： /META-INF/services/

2. 在其中创建一个名为 javax.xml.transform.TransformerFactory

3. 编辑该文件并将其内容设置为：com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl< /code>

就是这样！

为什么它有效？请参阅 Java 用于加载 Xalan 实现的此类。

请注意，对于特定的“META-INF”条目，它实际上似乎是一个父最后（或子优先）加载器（与常规 Java 类加载器的工作方式相反，例如父优先/子最后），但随意如果我错了

javax.xml.datatype.FactoryFinder 的代码片段，请纠正我

   /*
     * Try to find provider using Jar Service Provider Mechanism
     *
     * @return instance of provider class if found or null
     */
    private static Object findJarServiceProvider(String factoryId)
        throws ConfigurationError
    {

        String serviceId = "META-INF/services/" + factoryId;
        InputStream is = null;

        // First try the Context ClassLoader
        ClassLoader cl = ss.getContextClassLoader();
        if (cl != null) {
            is = ss.getResourceAsStream(cl, serviceId);

            // If no provider found then try the current ClassLoader
            if (is == null) {
                cl = FactoryFinder.class.getClassLoader();
                is = ss.getResourceAsStream(cl, serviceId);
            }
        } else {
            // No Context ClassLoader, try the current
            // ClassLoader
            cl = FactoryFinder.class.getClassLoader();
            is = ss.getResourceAsStream(cl, serviceId);
        }

        if (is == null) {
            // No provider found
            return null;
        }

        ...