Error unmarshalling xml in java-8 "secure-processing org.xml.sax.SAXNotRecognizedException causing java.lang.IllegalStateException"

We had a similar issue - our head developer found a solution that works for us.

We added this dependency to a couple of our pom.xml files

For those that care, the unit tests in Sonar that were failing were apparently failing because Cobatura by default pulls in an old version of xerces. The version it pulls in is incompatible with JAX-B in Java 8. The library is not used in production code – just Cobatura. Therefore, the fix was to add a test dependency on a more recent version of xerces (2.11.0). This is done by adding the dependency to the pom file:

<dependency>
    <groupId>xerces</groupId>
    <artifactId>xercesImpl</artifactId>
    <version>2.11.0</version>
    <scope>test</scope>
</dependency>

Xerces impl is the main culprit here. Remove it. Jdk has inbuilt jaxb parser, you don't need this.

so, if that dependency is coming from a parent project in case of maven use a exclusion tab in case you can't directly remove it.

<exclusion>
                 <groupId>xerces</groupId>  
            <artifactId>xercesImpl</artifactId> 
                </exclusion>

The reason this problem is so hard to detect is because, when you usually write a jaxb unmarshalling code

you will do a unmarshalling on a try block and then catch jaxb exception and then do whatever with the error.

But this culprit parser of a jar (xercesimpl) throws a runtime exception in the middle causing error to not get logged and will be only be detected after careful debugging. Look at the code snippet below

try {
JAXBContext context = JAXBContext.newInstance(YourClass.class);
            Unmarshaller unmarshaller = context.createUnmarshaller();
            YourClass object = (YourClass)unmarshaller.unmarshal(new StringReader("SomeXmlInString"));


}

catch (JAXBException e){
e.printStackTrace();

}

Here xercesImpl causes the unmarshaller to use some other sax parser (instead of the regular jaxb parser) causing it to throw different exception which won't be caught in our catch block which is expecting a jaxbexception or one of its subclasses.

Another possible solution to this is to add system variables:

I used these in the maven tomcat plugin which worked for me:

<javax.xml.parsers.DocumentBuilderFactory>com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl</javax.xml.parsers.DocumentBuilderFactory>
<org.xml.sax.parser>com.sun.org.apache.xerces.internal.parsers.SAXParser</org.xml.sax.parser>
<javax.xml.parsers.SAXParserFactory>com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl</javax.xml.parsers.SAXParserFactory>

But you should also be able to set as follows:

java -Dorg.xml.sax.parser="com.sun.org.apache.xerces.internal.parsers.SAXParser" \
-Djavax.xml.parsers.DocumentBuilderFactory="com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl" \
-Djavax.xml.parsers.SAXParserFactory="com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"

or even use System.setProperty:

System.setProperty("org.xml.sax.driver", "com.sun.org.apache.xerces.internal.parsers.SAXParser");
System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
System.setProperty("javax.xml.parsers.SAXParserFactory","com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl");