Tomcat sopraelevazione scegliere di classe percorso da file manifesto

Question

Tomcat Versione: 5.0.28 JDK: 1.5.0.14

Il problema:

Sto usando sia Hibernate e puntoni Non siamo sulla più recente e più grande della versione per queste librerie Sø- sia bisogno di una versione diversa della biblioteca apache-commons.

La soluzione che ho in mente:

Utilizzare file manifesto e specificare una diversa versione di apache-commons per ogni

La mia applicazione web viene distribuito come webapps \ myapp

E il lib è webapps \ myapp \ WEB-INF \ lib

Ho modificato il MANIFEST.MF in hibernate3.jar come segue

  

Manifest-Version: 1.0

     

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

e mettere lo slf4j-api-1.5.2.jar in webapps \ myapp \ WEB-INF \ lib \ hibernatelib

Ora mi aspetterei che slf4j-api-1.5.2.jar sarebbe caricato automaticamente insieme con Hibernate Ma la sua non funziona ... Tomcat è in grado di trovare i file jar specificati nel .MF come sopra

La questione:

1. Sto facendo qualcosa di sbagliato? o è Tomcat?
2. C'è un'altra soluzione a questo problema?

Ho già provato \ controllato il seguente

1. Controllato per caratteri di nuova riga alla fine del file
2. Se metto slf4j-api-1.5.2.jar nella lib principale cartella- l'errore va via- quindi so la sua non è in grado di trovare questo particolare file jar
3. relativa Provato, percorso assoluto nel file manifesto

Answer 1

L'unico luogo in cui viene utilizzato l'attributo Class-Path nel manifesto è quando il jar contenente il manifesto è chiamato come un vaso eseguibile utilizzando ( "java -jar theFile.jar").

Alcuni contenitori servlet sembrano sostenerlo, ma secondo a questa mailing list messaggio (Siamo spiacenti, couldn 't trovare qualcosa di più autorevole così in fretta) non è specificato nelle specifiche sia.

Per quanto mi risulta, le applicazioni web in genere caricano le loro classi utilizzando un unico class loader. "Correttamente" la risoluzione che la dipendenza problema richiederebbe almeno 2 differenti classloader.

Una soluzione hack-ish potrebbe essere quella di utilizzare jarjar uno strumento simile o per confezionare le diverse librerie insieme con i loro rispettivi dipendenze.

Quindi sarebbe produrre un jar contenente Hibernate insieme con la sua biblioteca apache-commons e un altro contenente jar montanti insieme con la sua biblioteca apache-commons. Ogni copia della libreria apache-commons sarebbe spostato in diversi pacchetti (possibilmente hibernate.org.apache.* e struts.org.apache.*) per risolvere il problema con diverse versioni Classe.

Answer 2

Hai controllato tutte le autorizzazioni siano corrette? Inoltre potrebbe essere un'idea per assicurarsi che ci sia un ritorno a capo dopo che la linea dell'ultimo Class-Path, che mi ha aiutato in precedenza oggi!

---

Aggiornamento: se Tomcat non supporta le dichiarazioni del percorso di classe come questo, l'unica cosa che viene in mente coinvolge fare in giro con ClassLoader. Personalmente non lo farei - c'è un intero mondo di potenziale dolore su questa strada e probabilmente un tempo più facile solo l'aggiornamento. Mi dispiace non riesco a pensare a una risposta migliore!

Answer 3

Hai provato l'ultima, più grande versione di Tomcat per vedere se il problema persiste? Tomcat 6 è già diversi anni, per non parlare di 5.5 o 5.0 ...

Answer 4

Non credo che si può fare questo. Tomcat non sta guardando manifesta JAR per decidere questioni classpath. E 'con una propria gerarchia di caricatori di classe per trovare ciò di cui ha bisogno, utilizzando quello che dice CLASSPATH è.

Se si desidera diverse versioni di un JAR per le diverse parti della vostra applicazione, suonare come una persona che ha davvero bisogno di OSGi . Questo è il problema è stato inventato per risolvere.

Ci sono due JSR concorrenti là fuori, ma non so di eventuali implementazioni per la proposta del modulo solarium.

Il server di un app che io sappia che vi permetterà di fare questo è server di DM di primavera . Si tratta di un fork di Tomcat che stanno migliorando.