parse - Error al desmarcar el xml en java-8 "Secure-processing org.xml.sax.SAXNotRecognizedException que causa java.lang.IllegalStateException"

xml to java object jaxb online

Question

El siguiente código funcionó bien en Java 7

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
String xmlString = ''<xml ..... '';
StringReader reader = new StringReader(xmlString);
JAXBContext jc = JAXBContext.newInstance(MyClass.class);
Unmarshaller unmarshaller = jc.createUnmarshaller();
MyClass myClass = (MyClass) unmarshaller.unmarshal(reader);
....

Ahora tuvimos que actualizar a Java 8 y ahora obtengo esta excepción al ejecutar el código:

Sep 03, 2014 1:42:47 PM com.sun.xml.internal.bind.v2.util.XmlFactory createParserFactory
SCHWERWIEGEND: null
org.xml.sax.SAXNotRecognizedException: Feature: http://javax.xml.XMLConstants/feature/secure-processing
at org.apache.xerces.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:100)
at com.sun.xml.internal.bind.v2.util.XmlFactory.createParserFactory(XmlFactory.java:114)
at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.getXMLReader(UnmarshallerImpl.java:139)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:214)

Sé que hay una question dirigida a un problema similar, pero retroceder a Java 7 no es una solución para mí.

Intenté agregar la siguiente dependencia maven

<dependency>
<groupId>javax.xml</groupId>
<artifactId>jaxp-api</artifactId>
<version>1.4</version>
</dependency>

pero eso no cambió el resultado, así que lo eliminé (gracias a @BlaiseDoughan por la información, esto está incluido en Java 6)

Cualquier consejo es bienvenido, muchas gracias.

Answer 1

Fue un problema de dependencia.

Aquí está mi manera cómo resolví el problema:

1. Haga un nuevo proyecto de Maven, con esas simples piezas de código, que adjunto a continuación, el programa se bloqueó normalmente con un error, que la estructura no se pudo analizar, lo cual está bien.

2. Copie sus dependencias en el proyecto pom.xml, ahora el programa debería fallar (como se describe anteriormente)

3. no se eliminan las dependencias después de su método favorito (adivinación correcta, Bisección, 1 por 1 ...) para encontrar la dependencia "incorrecta". Tal vez alguien tenga un método mejor (más profesional), este funcionó para mí.

ahora puede decidir qué hacer, tal vez haya una nueva versión disponible, en nuestro caso, fue un paquete propio de un colega, donde incluyó un paquete de un colega, que podría excluir.

public class Test {
public Test() {
}
public static void main(String[] args) {
try {
StringReader reader = new StringReader("<xml></xml>");
JAXBContext jc = JAXBContext.newInstance(TestXML.class);
Unmarshaller unmarshaller = jc.createUnmarshaller();
TestXML testXMLs = (TestXML) unmarshaller.unmarshal(reader);
} catch (JAXBException e) {
e.printStackTrace();
}
}
}

y la clase testXML

@XmlRootElement(name="rss")
@XmlAccessorType(XmlAccessType.FIELD)
public class TestXML {
public TestXML() {
}
@XmlElementWrapper(name="channel")
@XmlElement(name="item")
private int i ;
public int getI() {
return i;
}
public void setI(int i) {
this.i = i;
}
}

Por cierto: en mi caso fue

<dependency>
<groupId>jcs</groupId>
<artifactId>jcs</artifactId>
<version>1.3</version>
</dependency>

Espero que ayude.

Answer 2

Las respuestas de Bernard y Blaise fueron muy útiles. En mi caso, ya que estoy usando JDK 7, la solución fue excluir la subdependencia de xerces que estaba siendo incluida por una de mis dependencias:

<dependency>
<groupId>org.apache.axis</groupId>
<artifactId>axis</artifactId>
<version>1.4.1-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xmlParserAPIs</artifactId>
</exclusion>
</exclusions>
</dependency>

Answer 3

Me había enfrentado a un problema similar, este problema ocurre cuando hay una gran diferencia en las versiones de xerces jar y xercesImpl jar. Para resolver esto, utilicé xerces-2.9.0 y xercesImpl-2.9.1 y el problema desapareció.

Answer 4

Otra posible solución a esto es agregar variables de sistema:

Utilicé estos en el plugin maven tomcat que funcionó para mí:

<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>

Pero también debería ser capaz de establecer lo siguiente:

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"

o incluso utilizar 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");

Answer 5

Resolví este problema en mi proyecto con la segunda solución de Mitch, pero solo con

java -Djavax.xml.parsers.SAXParserFactory="com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"

Answer 6

Se ha incluido una implementación de JAXB en Java SE desde la versión 6. Si elimina la dependencia de Maven (que probablemente esté causando un conflicto de versión), todo debería funcionar.

Answer 7

También resolvimos el problema y notamos que necesita mantener la versión jdk y la versión jre igual, de lo contrario existirá la discrepancia en la versión que causó el problema

Los tipos que resolvieron el problema utilizan jdk1.6 y jre 1.8, cuando se cambió a ambos jdk1.6, el problema desapareció.

Answer 8

Trate de crear un documento XML y descomprimirlo. Fue trabajado para mí. JAXBContext jc = JAXBContext.newInstance (Message.class);

 InputStream stream = new ByteArrayInputStream( string.getBytes( StandardCharsets.UTF_8 ) );
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse( stream );
Unmarshaller unmarshaller = jc.createUnmarshaller();
Message msg = ( Message ) unmarshaller.unmarshal( doc );

Answer 9

Tuvimos un problema similar: nuestro desarrollador principal encontró una solución que funciona para nosotros.

Agregamos esta dependencia a un par de nuestros archivos pom.xml

Para aquellos a los que les importa, las pruebas de unidad en Sonar que estaban fallando aparentemente estaban fallando porque Cobatura por defecto saca una versión antigua de xerces. La versión que incorpora no es compatible con JAX-B en Java 8. La biblioteca no se usa en el código de producción, solo Cobatura. Por lo tanto, la solución fue agregar una dependencia de prueba en una versión más reciente de xerces (2.11.0). Esto se hace agregando la dependencia al archivo pom:

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

Answer 10

Usar SAXparser puede ser una pesadilla. Este es el analizador XML más utilizado en java y todos han terminado por usarlo de forma directa o indirecta. JDK 8 ya tiene JAXB disponible. Por lo tanto, si está utilizando JDK 8, la única forma posible sería eliminar la dependencia de Maven. También tuve este problema, así que intenté eliminar la dependencia de Maven pero no sucedió. Entonces pensé, ¿por qué no volver a la versión anterior si java y VOILLA obtuve el éxito? Estoy usando jdk 7 actualmente y mis pruebas se ejecutan sin problemas. Supongo que esta es la única solución.

Answer 11

Xerces impl es el principal culpable aquí. Quitarlo Jdk ha incorporado el analizador jaxb, no necesitas esto.

por lo tanto, si esa dependencia proviene de un proyecto principal en caso de que Maven use una pestaña de exclusión en caso de que no pueda eliminarlo directamente.

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

La razón por la que este problema es tan difícil de detectar es porque, cuando usualmente escribes un código jaxb no irrelevante

Hará un poco riguroso en un bloque try y luego capturará la excepción jaxb y luego hará lo que sea con el error.

Pero este analizador culpable de un jar (xercesimpl) lanza una excepción de tiempo de ejecución en el medio, lo que provoca que el error no se registre y solo se detectará después de una depuración cuidadosa. Mira el fragmento de código a continuación

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

En este caso, xercesImpl hace que el implacable use otro analizador de sax (en lugar del analizador jaxb regular) causando que lance una excepción diferente que no se detectará en nuestro bloque catch, que espera una jaxbexception o una de sus subclases.