2011-10-17 17 views
9

En mi proyecto actual, nos dirigimos a un entorno de tiempo de ejecución de JDK 1.6. Para los rasones heredados, los archivos Xerces JAR se incluyen en la aplicación.JDK 1.6 y Xerces?

¿Estas ya no son necesarias? El JDK tiene (por un tiempo) bibliotecas de análisis XML incluidas en el JDK?

+0

¿Por qué no intentarlo sin agruparlos? –

+1

No son más o menos necesarios que con 1.5. 1.6 tiene alguna extraña versión bifurcada de Xerces, solo una versión extraña diferente de 1.5. Según @DaveNewton, la única manera de saber si funcionará para usted es intentarlo. – bmargulies

+0

Creo que tengo que ejecutar algún software de análisis de dependencia en nuestro proyecto. No estaría seguro si algún framework de código abierto que usamos dependa directamente de Xerces en lugar de usar JAXP. –

Respuesta

12

No ha sido necesario agrupar un analizador XML desde 1.4 cuando se agregó JAXP al JRE. Debería usar JAXP y no llamar directamente a Xerces. Internamente, JRE agrupa y usa Xerces de todos modos (con un prefijo "com.sun").

+3

Esto es correcto. Después de buscar en Google, parece que JDK 1.4 tenía soporte para JAXP 1.1 y se incluía el Apache clasificado con nombres de clases sin clasificar; causando un montón de problemas cuando las personas querían usar versiones más nuevas que la que se incluye con el JDK. (http://people.apache.org/~edwingo/jaxp-faq.html#JDK14) –

20

Estos servicios XML se conectan al entorno de la aplicación utilizando el denominado mecanismo de "proveedor de servicios".

funciona de la siguiente manera:

  1. Se trata de encontrar la propiedad del sistema que iguala exactamente los puntos a clase de fábrica, que se debe utilizar. P.ej. -Djavax.xml.parsers.SAXParserFactory=<some class>.
  2. Si no se encontró la propiedad del sistema FactoryFinder busca la propiedad en el archivo de propiedades especiales. Por ejemplo ${java.home}/lib/jaxp.properties.
  3. Si no se encontró la propiedad del archivo, FactoryFinder busca la descripción del servicio en la ruta de clase META-INF/services/<some service>, p. META-INF/services/javax.xml.parsers.SAXParserFactory. Es un archivo que debe contener el nombre de clase de fábrica, por ejemplo org.apache.xerces.jaxp.SAXParserFactoryImpl.
  4. Si no hay tales archivos en el camino de clase, java usa su implementación predeterminada de fábrica.

Así que si no tiene la propiedad del sistema apuntando a la clase de fábrica evidente, java elegirá la implementación adecuada en silencio.

+1

Gracias por una respuesta muy útil, incluso si no respondió mi pregunta. –

+4

Esta es la forma en que funciona el código estándar estático 'SAXParserFactory', consulte [enlace] (http://docs.oracle.com/javase/7/docs/api/javax/xml/parsers/SAXParserFactory.html#newInstance%28 % 29) para estos y algunos detalles más. Estas son las formas de acoplar los mecanismos iniciales de JDK/JRE con una biblioteca XML de su elección. También existe la posibilidad de sustituir las bibliotecas XML integradas de JDK/JRE por completo mediante el mecanismo de anulación de las normas aprobadas por jva: _ http://docs.oracle.com/javase/7/docs/technotes/guides/standards/, p. Ej. '-Djava.endorsed.dirs = path_to_folder_containing_new_library_jars'. –

11

El analizador en el JDK era una bifurcación de Xerces, pero es muy defectuoso. Recomendaría a las aplicaciones de producción que siempre usen la versión de Apache del analizador. Los errores son raros, pero son impredecibles, y no solo afectan los casos de esquina que no se ven en la vida real; He visto muchos casos en los que se analizan documentos XML bastante aburridos y se pasan datos corruptos a la aplicación para obtener valores de atributos. Sun/Oracle no han mostrado interés en solucionar el problema. Use Apache Xerces todo el tiempo.

+1

Hola. ¿Tiene algunas referencias/descripciones de errores en el analizador sintáctico JDK? ¿Y de qué versiones de JDK estás hablando? –

+0

Cuando las personas me envían informes de errores de Saxon que se deben a problemas del analizador JDK, ya no me molesto en informar los problemas a Oracle porque hacerlo no parece tener ningún efecto. Entonces no, no puedo citar referencias. –

1

Endorsed Standards Override Mechanism funciona muy bien. Djava.endorsed.dirs = path_to_folder_containing_new_library_jars resolverá el problema con JDK 1.6.

He verificado la solución anterior en el contexto de Thymleaf. En algunos casos, si utiliza el modo LEGACYHTML5 y utiliza el analizador NekoHtml para la autocorrección de las etiquetas html sin cerrar, Neko depende de Xerces jar. Establecer el classpath no resuelve el problema.

Gracias s-n-ushakov.

Cuestiones relacionadas