by jason » Thu Feb 05, 2015 8:58 pm
Some background on docx4j and xml properties below.
What JDK are you using? As per the below, docx4j would ordinarily use xerces. AElfred seems problematic.
javax.xml.parsers.SAXParserFactory
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() )
javax.xml.transform.TransformerFactory
docx4j tries to use the 'real' Xalan, "org.apache.xalan.processor.TransformerFactoryImpl"
It needs this for XSLT to work (since where docx4j uses XSLT, it often uses Xalan extension functions to invoke docx4j java code from the XSLT)
Xalan would also be used for XPath queries, so you're in unsupported territory if you do XPath queries without Xalan.
Once docx4j has a TransformerFactory, it sets the system property back to what it was, so there shouldn't be a system wide impact.