views:

490

answers:

2

I would like to provide diagnostic information about what JAXP implementation is in use, and which JAR file it was loaded from.

One way to achieve this is to create in instance of, for example, a DocumentBuilderFactory, and then inspect the properties of that class:

private static String GetJaxpImplementation() {
    DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
    Class<? extends DocumentBuilderFactory> c = documentBuilderFactory.getClass();
    Package p = c.getPackage();
    CodeSource source = c.getProtectionDomain().getCodeSource();
    return MessageFormat.format(
            "Using JAXP implementation ''{0}'' ({1}) version {2} ({3}){4}",
            p.getName(),
            p.getImplementationVendor(),
            p.getSpecificationVersion(),
            p.getImplementationVersion(),
            source == null ? "." : " loaded from: " + source.getLocation());
}

Is there a better way to achieve this, perhaps without having to create a DocumentBuilderFactory?

+1  A: 

It depends, but generally no.

DocumentBuilderFactory.newInstance() will either return the implementation of DocumentBuilderFactory which is configured in the system property "javax.xml.parsers.DocumentBuilderFactory" or the JRE's default factory if the system property is not set. The default factory is most likely hard coded in the implementation of the newInstance method and not otherwise accessible.

If the system property is set, you could at least use the getResource method on the relevant class loader to get the URL, from which the class loader would load the corresponding class file. If it is from a jar file, you should be able to extract the file name (or source URL) from the jar: URL. Detailed package information should also be available if you manaully read the meta data files from the classpath.

If the system property is not set, I'm pretty sure that you have no way to get the information you are looking for without actually creating a new factory as you're already doing.

jarnbjo
+3  A: 

It is quite difficult to predict what concrete JAXP factory implementation will be loaded without actually creating an instance because the process for selecting an implementation.

From the Official JAXP FAQ (Question 14):

When an application wants to create a new JAXP DocumentBuilderFactory instance, it calls the staic method DocumentBuilderFactory.newInstance(). This causes a search for the name of a concrete subclass of DocumentBuilderFactory using the following order:

  1. The value of a system property like javax.xml.parsers.DocumentBuilderFactory if it exists and is accessible.
  2. The contents of the file $JAVA_HOME/jre/lib/jaxp.properties if it exists.
  3. The Jar Service Provider discovery mechanism specified in the Jar File Specification. A jar file can have a resource (i.e. an embedded file) such as META-INF/services/javax.xml.parsers.DocumentBuilderFactory containing the name of the concrete class to instantiate.
  4. The fallback platform default implementation.

Adding to this complexity, each individual JAXP factory can have an independent implementation specified. It is common to use one parser implementation and another XSLT implementation, but the granularity of the selection mechanism above allows you to mix and match to an even greater degree.

The following code will output information about the four main JAXP factories:

private static void OutputJaxpImplementationInfo() {
    System.out.println(getJaxpImplementationInfo("DocumentBuilderFactory", DocumentBuilderFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("XPathFactory", XPathFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("TransformerFactory", TransformerFactory.newInstance().getClass()));
    System.out.println(getJaxpImplementationInfo("SAXParserFactory", SAXParserFactory.newInstance().getClass()));
}

private static String getJaxpImplementationInfo(String componentName, Class componentClass) {
    CodeSource source = componentClass.getProtectionDomain().getCodeSource();
    return MessageFormat.format(
            "{0} implementation: {1} loaded from: {2}",
            componentName,
            componentClass.getName(),
            source == null ? "Java Runtime" : source.getLocation());
}

The following sample output illustrates a mix-and-match of three different JAXP implementations (Built-in Xerces and external JARs for Xerces 2.8 and Xalan) working together:

DocumentBuilderFactory implementation: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xerces-2.8.0.jar
XPathFactory implementation: com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl loaded from: Java Runtime
TransformerFactory implementation: org.apache.xalan.processor.TransformerFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xalan.jar
SAXParserFactory implementation: org.apache.xerces.jaxp.SAXParserFactoryImpl loaded from: file:/C:/Projects/Scratch/lib/xerces-2.8.0.jar
Daniel Fortunov