¿Cómo configurar Saxon como el procesador Xslt en Java?
(3)
Esta es una pregunta simple, pero no puedo encontrar la respuesta. Tengo una hoja de estilos XSLT 2.0 que estoy tratando de procesar en Java. Se basa en elementos XSL de Saxon.
Mi clase actual funciona bien con XSLT 1.0 simple, pero recibo errores sobre elementos no reconocidos con mi 2.0 XSLT construido con Saxon.
No puedo entender cómo decirle a Java que use Saxon como procesador. Estoy usando javax.xml.transform en mi clase. ¿Es esta una propiedad que puedo establecer? ¿A qué lo configuro? ¡Gracias!
Editado Descubrí cómo configurar la propiedad para usar Saxon, pero ahora recibo este error.
Provider net.sf.saxon.TransformerFactoryImpl not found
¿Cómo incluyo Saxon en mi aplicación?
Hay varias formas de hacerlo (en orden de prioridad de búsqueda):
Instanciación directa
Instalar explícitamente la fábrica de Saxon (con un guiño al comentario de Michael anterior):
TransformerFactory fact = new net.sf.saxon.TransformerFactoryImpl()
Este enfoque significa que su código está bloqueado en el uso de Saxon en tiempo de compilación. Esto se puede ver como una ventaja (no hay riesgo de que se ejecute con el procesador incorrecto) o una desventaja (no hay oportunidad de configurar un procesador diferente en el momento de la ejecución, ni siquiera Saxon Enterprise Edition).
Para Saxon-PE, sustituya com.saxonica.config.ProfessionalTransformerFactory . Para Saxon-EE, sustituya com.saxonica.config.EnterpriseTransformerFactory .
Especifique el nombre de la clase
Especifique la clase de fábrica al construirlo:
TransformerFactory fact = TransformerFactory.newInstance(
"net.sf.saxon.TransformerFactoryImpl", null);
Nota: disponible a partir de Java 6 . La versión de Java 5 no tiene este método.
Este enfoque le permite elegir el procesador en el momento de la ejecución, al mismo tiempo que evita los costos y riesgos de una búsqueda de ruta de clase. Por ejemplo, su aplicación podría proporcionar algún mecanismo de configuración para permitir que se ejecute con diferentes ediciones de Saxon eligiendo entre las diversas clases de fábrica de Saxon.
Usar propiedad del sistema
Establezca la propiedad del sistema javax.xml.transform.TransformerFactory antes de crear una instancia:
System.setProperty("javax.xml.transform.TransformerFactory",
"net.sf.saxon.TransformerFactoryImpl");
O en la línea de comando (línea rota para la legibilidad):
java -Djavax.xml.transform.TransformerFactory=
cnet.sf.saxon.TransformerFactoryImpl YourApp
Este enfoque tiene la desventaja de que las propiedades del sistema afectan a toda la máquina virtual de Java. Establecer esta propiedad para seleccionar Saxon podría significar que algún otro módulo en la aplicación, del cual ni siquiera se conozca, comienza a usar Saxon en lugar de Xalan, y ese módulo podría fallar como resultado si usa construcciones XSLT específicas de Xalan.
Usar archivo de propiedades
Crea el siguiente archivo:
JRE/lib/jaxp.properties
Con los siguientes contenidos:
javax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl
Este enfoque tiene consecuencias similares al uso de la propiedad del sistema.
Cargador de servicio
Cree el siguiente archivo en cualquier JAR en CLASSPATH:
META-INF/services/javax.xml.transform.TransformerFactory
Con los siguientes contenidos:
net.sf.saxon.TransformerFactoryImpl
Este enfoque tiene la desventaja de que un pequeño cambio en la ruta de clases podría hacer que la aplicación se ejecute con un motor XSLT diferente, tal vez con el que nunca se haya probado la aplicación.
Plataforma predeterminada
Si no se hace ninguno de los pasos anteriores, se cargará la instancia de TransformerFactory predeterminada de la plataforma. Una descripción amigable de esta capa de plugabilidad se puede encontrar here .
Tenga en cuenta que ''plataforma'' aquí significa Java VM, no el hardware o el sistema operativo en el que se está ejecutando. Para todas las máquinas virtuales Java conocidas actuales, la plataforma predeterminada es una versión de Xalan (que solo es compatible con XSLT 1.0). No hay garantía de que esto siempre sea cierto para todas las VM de Java en el futuro.
Consideraría esta respuesta como un argumento en contra de la forma de hacer las cosas en Java.
Puede construir explícitamente los objetos Source y Result requeridos para asegurarse de que sean implementaciones Saxon en lugar de cualquiera que sean las predeterminadas.