Conflictos en la cadena de dependencia para Hibernate y Apache Felix

Entiendo el concepto de OSGi quejándose de múltiples cadenas de dependencia: un paquete está disponible más de una vez y cuando el paquete de importación no especifica exactamente qué versión necesita, por lo que el contenedor OSGi puede tener la molestia de no saber qué proporcionar.

Lamentablemente, me encontré con un problema así esta semana, pero los dos paquetes involucrados son paquetes de terceros, por lo que realmente no puedo influir en sus importaciones y exportaciones. Aquí están los dos mensajes de error que recibo:

org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision org.hibernate.core [28.0] because it is exposed to package 'javax.xml.stream' from bundle revisions com.springsource.javax.xml.stream [23.0] and org.apache.felix.framework [0] via two dependency chains. Chain 1: org.hibernate.core [28.0] import: (osgi.wiring.package=javax.xml.stream) | export: osgi.wiring.package=javax.xml.stream com.springsource.javax.xml.stream [23.0] Chain 2: org.hibernate.core [28.0] import: (osgi.wiring.package=javax.xml.transform.stax) | export: osgi.wiring.package=javax.xml.transform.stax; uses:=javax.xml.stream export: osgi.wiring.package=javax.xml.stream org.apache.felix.framework [0] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3824) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Thread.java:724) org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision org.hibernate.core [28.0] because it is exposed to package 'javax.xml.stream' from bundle revisions org.apache.felix.framework [0] and com.springsource.javax.xml.stream [23.0] via two dependency chains. Chain 1: org.hibernate.core [28.0] import: (osgi.wiring.package=javax.xml.stream) | export: osgi.wiring.package=javax.xml.stream org.apache.felix.framework [0] Chain 2: org.hibernate.core [28.0] import: (osgi.wiring.package=org.dom4j.io) | export: osgi.wiring.package=org.dom4j.io; uses:=javax.xml.stream com.springsource.org.dom4j [27.0] import: (&(osgi.wiring.package=javax.xml.stream)(version>=1.0.1)(!(version>=2.0.0))) | export: osgi.wiring.package=javax.xml.stream com.springsource.javax.xml.stream [23.0] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3824) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Thread.java:724) 

Cuando bash eliminar com.springsource.javax.xml.stream de los paquetes instalados, com.springsource.org.dom4j queja de que falta el paquete javax.xml.stream .

MANIFEST.MF archivo MANIFEST.MF de org.apache.felix.framework porque estaba realmente asombrado de que Felix aparentemente exportara javax.xml.stream , pero no contiene tal entrada. Además, el paquete dom4j no reexporta el paquete de transmisión de acuerdo con su manifiesto.

Estaré realmente agradecido por cualquier consejo que pueda acercarme más a responder la pregunta de dónde proviene este problema de la cadena de dependencia. Desde mi punto de vista no pude encontrar un paquete además de com.springsource.javax.xml.stream exportando dicho com.springsource.javax.xml.stream

A menudo es un problema si un paquete está disponible en un paquete y también en el bpot classpath (JDK). Es incluso un problema mayor si ese paquete está conectado desde otro paquete JDK y también desde un paquete directamente. En tu caso el problema es el siguiente:

  • javax.xml.transform.stax está disponible solo en la ruta de clase de inicio (JDK), por lo que hibernate.core se conecta a ese paquete.
  • Como javax.xml.transform.stax proviene de la ruta de clase de inicio, puede conectarse a otro paquete en la ruta de clase de inicio. Necesita javax.xml.stream para que se conecte al paquete que viene de JDK

Tenemos la cadena:

 hibernate.core -> javax.xml.transform.stax -> javax.xml.stream 

Por otro lado, hibernate.core se conecta directamente a javax.xml.stream. Probablemente incluso usa una versión en la sección Import-Package, por lo que no puede conectarse al paquete que viene de JDK.

Tenemos la cadena:

 hibernate.core -> javax.xml.stream 

Esto genera un conflicto. Como hibernate.core usa la API javax.xml.stream con la ayuda de javax.xml.transform.stax , hibernate.core y javax.xml.transform.stax deben usar las mismas clases de javax.xml.stream . Sin embargo, no lo hacen.

Tienes un par de opciones para resolver tu problema:

Puede instalar un paquete que contenga el paquete javax.xml.transform.stax . Ese paquete podrá conectarse al paquete javax.xml.stream que proviene del paquete y también hibernate.core puede conectarse al paquete que contiene javax.xml.transform.stax . Puedes rezar para que los cableados estén siempre bien.

En mi experiencia, los cables son buenos después de que se inicia el marco. Como las versiones del paquete son más altas en los paquetes, se preferirán cuando el paquete se importe de otros paquetes. Sin embargo, cuando los paquetes se actualizan y actualizan en tiempo de ejecución, el cableado a menudo falla. No sé por qué, simplemente sucede.

Para evitar todos los problemas, normalmente excluyo esos paquetes de la ruta de clase de arranque que también están disponibles en paquetes.

Su siguiente problema podría ser que estas API a menudo usan clases de fábrica. Cuando alguien usa dicha fábrica, el cargador de clases de la clase de fábrica también debe ver las clases de implementación. Creé un paquete que contiene todos los paquetes xmlcommons. Contiene todas las clases xml-apis y su implementación (xerces, xalan, etc.). Podría ser útil para usted. Si este paquete resuelve su problema, hágamelo saber. En ese caso, finalmente me tomaré el tiempo de recostackr todos los datos necesarios (licencias en el pom, fonts) y entregarlos a maven-central para que pueda ayudar a otros también.