Pregunta

Versión Tomcat: 5.0.28 JDK: 1.5.0.14

El problema:

Estoy utilizando tanto Hibernate y puntales No estamos en la mejor y más nuevo de la versión de estas bibliotecas Sø- ambos necesitan una versión diferente de la biblioteca Apache-comunes.

La solución que tengo en mente:

Usar archivo de manifiesto y especificar una versión diferente de apache-comunes para cada

Mi aplicación web se implementa como webapps \ miaplicacion

Y el lib es webapps \ miaplicacion \ WEB-INF \ lib

I modificado el MANIFEST.MF en hibernate3.jar como sigue

  

Manifiesto-Version: 1.0

     

Archiver-Version: Plexo Archiver   Creado-By: 1.5.0_15-b04 (Sun> Microsystems Inc.)   Class-Path: hibernatelib / slf4j-api-1.5.2.jar

y poner el slf4j-api-1.5.2.jar en webapps \ miaplicacion \ WEB-INF \ lib \ hibernatelib

Ahora yo esperaría que slf4j-api-1.5.2.jar se carga automáticamente junto con Hibernate Pero no su trabajo ... Tomcat es incapaz de encontrar los archivos jar especificados en el .MF que el anterior

La Pregunta:

  1. ¿Estoy haciendo algo mal? o se trata de Tomcat?
  2. ¿Hay alguna otra solución a este problema?

Ya he probado \ comprobado lo siguiente:

  1. Se verificó la caracteres de nueva línea al final del archivo
  2. Si pongo slf4j-api-1.5.2.jar en el lib principal carpeta- el error de distancia-va, así que sé que no es capaz de encontrar el archivo jar en particular
  3. relativa intentado, ruta absoluta en el archivo de manifiesto
¿Fue útil?

Solución

El único lugar donde se utiliza el atributo Class-Path en el manifiesto es cuando el jar que contiene el manifiesto se llama como un tarro ejecutable usando ( "java -jar theFile.jar").

Algunos contenedores de servlets parecen apoyarla, pero de acuerdo a esta lista de correo posterior (Lo sentimos, couldn 't encontrar nada más authorative tan rápidamente) no se especifica en la especificación tampoco.

Por lo que yo entiendo, aplicaciones web en general, cargan sus clases utilizando un único cargador de clases. "Correctamente" la solución de ese problema dependencia requeriría por lo menos 2 cargadores de clases diferentes.

Una solución hack-ish podría ser utilizar jarjar o una herramienta similar para empaquetar las diferentes bibliotecas, junto con sus respectivas dependencias.

Así que es producir un jar contiene Hibernate junto con su biblioteca de Apache-Commons y otro que contiene jar puntales junto con su biblioteca de Apache-Commons. Cada copia de la biblioteca Apache-commons se trasladó a diferentes paquetes (posiblemente hibernate.org.apache.* y struts.org.apache.*) para resolver el problema con diferentes versiones classe.

Otros consejos

Ha comprobado los permisos son correctos? También podría ser una buena idea para asegurarse de que hay una nueva línea después de que la última línea de Class-Path, que me ayudó a cabo el día de hoy!


Actualización: si Tomcat no es compatible con las declaraciones de ruta de clases de este tipo, la única cosa que viene a la mente consiste en jugar un poco con los cargadores de clases. En lo personal yo no haría eso - hay todo un mundo de posibilidades dolor por ese camino y es probable que les resulta más fácil simplemente actualizar. Lo siento, no puedo pensar en una mejor respuesta!

¿Has probado la última, más grande versión de Tomcat para ver si el problema persiste? Tomcat 6 es ya varios años, y mucho menos 5.5 o 5.0 ...

No creo que se puede hacer esto. Tomcat no está mirando a los manifiestos JAR para decidir cuestiones de CLASSPATH. Se trata de utilizar su propia jerarquía de los cargadores de clases para encontrar lo que necesita, usando lo que dice es CLASSPATH.

Si quieres diferentes versiones de un archivo JAR para diferentes partes de su aplicación, que suena como una persona que realmente necesita OSGi. Ese es el problema se fue inventado para resolver.

Hay dos JSRs compiten por ahí, pero no sé de cualquier implementación de la propuesta módulo solar.

El servidor de una aplicación, que yo sepa que le permitirá hacer esto es servidor de DM de la primavera . Es un tenedor de Tomcat que están mejorando.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top