CODEWITHSUNDEEP
javaxmltomcatdocx4jopensaml
jfhfmn
jfhfmn

Reputation: 21

Random error with OpenSAML XML Parser Configuration

I'm running a webapp in Tomcat 8 that uses OpenSAML. I've endorsed Xerces within Tomcat, I've checked that the endorsed dir path is set right, it appears that everything is working fine:

[ajp-apr-8009-exec-22] DEBUG org.opensaml.xml.Configuration - VM using JAXP parser org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

I get several requests that work just fine, everything seems great, I can run through that section of code without error, then all of a sudden, I start getting this error:

OpenSAML requires an xml parser that supports JAXP 1.3 and DOM3. The JVM is currently configured to use the Sun XML parser, which is known to be buggy and can not be used with OpenSAML. Please endorse a functional JAXP library(ies) such as Xerces and Xalan. For instructions on how to endorse a new parser see http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html

    at org.opensaml.xml.Configuration.validateNonSunJAXP(Configuration.java:278)
    at org.opensaml.xml.parse.BasicParserPool.<init>(BasicParserPool.java:126)

Once I start getting the error, I will get an error every time but I haven't been able to isolate what it takes to trigger the problem. (Edit: it appears that this may be related in some way to docx4j usage, the errors start after a request that uses docx4j to generate a file as a word document. Since docx4j is so reliant on XML, this maybe makes some sense.)

Basically, what validateNonSunJAXP() does is pretty simple. All it does is check the class name for the DocumentBuilderFactory and if it starts with "com.sun", it throws the error.

Any ideas on what could be going on that would cause the VM to stop using the endorsed library?

Upvotes: 1

Views: 2067

Answers (1)

JasonPlutext
JasonPlutext

Reputation: 15863

docx4j manipulates:

  • javax.xml.parsers.SAXParserFactory
  • javax.xml.parsers.DocumentBuilderFactory
  • javax.xml.transform.TransformerFactory

You can see what it does, at https://github.com/plutext/docx4j/blob/master/src/main/java/org/docx4j/XmlUtils.java

javax.xml.parsers.SAXParserFactory

In summary, you can prevent docx4j from touching this value via a docx4j properties setting.

We found Crimson fails to parse docx4j XSLT files, which is why docx4j by default tries to use Xerces, where it is included in the JDK. (Things may be better in more recent JDKs)

If you don't want this, you can specify different behaviour via docx4j.properties:

  • docx4j.javax.xml.parsers.SAXParserFactory.donotset=true stops docx4j from changing the setting, or
  • javax.xml.parsers.SAXParserFactory allows you to specify what you want

Note that we don't restore the value to its original setting since we want to avoid Crimson being used for the life of the application.

javax.xml.parsers.DocumentBuilderFactory

This works similarly to SAXParserFactory

The relevant docx4j properties are as follows:

  • docx4j.javax.xml.parsers.DocumentBuilderFactory.donotset
  • javax.xml.parsers.DocumentBuilderFactory

We don't restore the value to its original setting (though maybe we could; would need to review whether docx4j always uses XmlUtils.getNewDocumentBuilder() )

Upvotes: 1

Related Questions