NullPointerException in weblogic's DOMFactoryProperties when parsing an XML document under Tomcat

Question

I'm trying to parse an XML and getting a weirdest NullPointerException I've ever seen. Here's the stack trace:

java.lang.NullPointerException
    at java.util.Hashtable.put(Hashtable.java:399)
    at weblogic.xml.jaxp.DOMFactoryProperties.<init>(DOMFactoryProperties.java:44)
    at weblogic.xml.jaxp.DOMFactoryProperties.clone(DOMFactoryProperties.java:114)
    at weblogic.xml.jaxp.RegistryDocumentBuilderFactory.newDocumentBuilder(RegistryDocumentBuilderFactory.java:140)
    at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.createDocument(SAX2DOM.java:324)
    at com.sun.org.apache.xalan.internal.xsltc.trax.SAX2DOM.<init>(SAX2DOM.java:84)
    at com.sun.org.apache.xalan.internal.xsltc.runtime.output.TransletOutputHandlerFactory.getSerializationHandler(TransletOutputHandlerFactory.java:187)
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getOutputHandler(TransformerImpl.java:392)
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerHandlerImpl.setResult(TransformerHandlerImpl.java:137)
    at com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader$State.<init>(DomLoader.java:74)
    at com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.startElement(DomLoader.java:113)
    at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:55)
    at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:455)
    at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:433)
    at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:137)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2755)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
    at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
    at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
    at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
    at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
    at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:133)
    at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:173)
    at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:211)
    at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:184)
    at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:137)
    at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:105)
    at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:584)
    at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmarshal(Jaxb2Marshaller.java:571)

Firstly, it only happens when my app is deployed under Tomcat (I'm using weblogic client JAR to connect to external weblogic JMS queues). I could not reproduce it in my tests outside of Tomcat. So I suspect some class loader weirdness or something.

Secondly, I tried to decompile DOMFactoryProperties class and here's a constructor that's causing that NPE:

public class DOMFactoryProperties
{
  public static String COALESCING = "Coalescing";
  public static String EXPANDENTITYREFERENCES = "ExpandEntityReferences";
  public static String IGNORINGCOMMENTS = "IgnoringComments";
  public static String IGNORINGELEMENTCONTENTWHITESPACE = "IgnoringElementContentWhitespace";
  public static String NAMESPACEAWARE = "Namespaceaware";
  public static String VALIDATING = "Validating";

  public static String SCHEMA = "Schema";

  public static String XINCL = "XIncludeAware";
  private Hashtable factoryProperties;
  private Set facPropertySettingMarks;
  private LinkedHashMap attributes;

  public DOMFactoryProperties()
  {
    this.factoryProperties = new Hashtable();
    this.factoryProperties.put(COALESCING, Boolean.FALSE);
    this.factoryProperties.put(EXPANDENTITYREFERENCES, Boolean.TRUE);
    this.factoryProperties.put(IGNORINGCOMMENTS, Boolean.FALSE);
    this.factoryProperties.put(IGNORINGELEMENTCONTENTWHITESPACE, Boolean.FALSE);
    this.factoryProperties.put(NAMESPACEAWARE, Boolean.FALSE);
    this.factoryProperties.put(VALIDATING, Boolean.FALSE);
    this.factoryProperties.put(XINCL, Boolean.FALSE);

    this.facPropertySettingMarks = new HashSet();

    this.attributes = new LinkedHashMap();
  }

//...
}

It's failing on the line this.factoryProperties.put(COALESCING, Boolean.FALSE);. The only cause for that could be null value in COALESCING, but unless some other class is setting that to null (as it is public static for some reason) from outside I don't see why it can be null.

Any idea?

Is there any way to tell Spring's Jaxb2Marshaller to not use XML reader from weblogic?

UPDATE: To make things worse this is not even always reproducible under Tomcat for the same XML. Sometimes it works, sometimes it doesn't.

UPDATE2: Debug shows that weblogic.xml.jaxp.DOMFactoryProperties.COALESCING is indeed null. But why?

UPDATE3: It looks like I can tell which implementation of SAXParserFactory to use by setting javax.xml.parsers.SAXParserFactory system property to com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl (platform default). The other question still remains.

Answer 1

Thanks A LOT @Piotr De !

I had this exception:

java.lang.NullPointerException at com.sun.org.apache.xalan.internal.xsltc.runtime.output.TransletOutputHandlerFactory.getSerializationHandler(TransletOutputHandlerFactory.java:186) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getOutputHandler(TransformerImpl.java:453) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:336) at com.xml.fda.sciencepapers.service.impl.DisplayServiceImpl.generateHTML(DisplayServiceImpl.java:114)

...

Line 114 in DisplayServiceImpl calls the transform method of javax.xml.transform.Transformer.

I resolved the problem by added the xalan dependency to my pom like this:

    <!-- https://mvnrepository.com/artifact/xalan/xalan -->
    <dependency>
        <groupId>xalan</groupId>
        <artifactId>xalan</artifactId>
        <version>2.7.2</version>
    </dependency>

And then got some Serializer class not found Exception, and I added this dependency also:

<!-- https://mvnrepository.com/artifact/xalan/serializer -->
    <dependency>
        <groupId>xalan</groupId>
        <artifactId>serializer</artifactId>
        <version>2.7.2</version>
    </dependency>

Here is the link to download the serializer jar.

Note: I created the lib folder myself, placed it in the resources folder and placed the jars in it.

Edit: Stroke through the above text because I changed the place from where I get the jars from a local folder to the maven repository.

Answer 2

We had similar issue one time, also occurring only on Tomcat. As I can see your application uses apache xalan (take a look at the stack trace). Our deep investigation proven that it was caused by inappropriate instantiation of parser factory (as I remember) - probably some strange conflicts between libraries. In our case, adding xalan JAR to the project maven dependencies (it should be available in the lib directory of your webapp) solved the problem. I mean - we had to add this dependency explicitly even if project built successfully without it.