Tomcat não pode escolher Class-Path do arquivo de manifesto

Question

Tomcat Versão: 5.0.28 JDK: 1.5.0.14

O problema:

Eu estou usando tanto hibernate e struts Nós não estamos na melhor e mais recente da versão para essas bibliotecas Tão- tanto necessidade uma versão diferente da biblioteca apache-commons.

A solução que eu tenho em mente:

Use o arquivo de manifesto e especificar uma versão diferente do apache-commons para cada

Meu aplicativo web é implantado como webapps \ myapp

E o lib é webapps \ myapp \ WEB-INF \ lib

Eu modifiquei o Manifest.mf em hibernate3.jar como segue

Manifest-Version: 1.0

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

e colocar o slf4j-api-1.5.2.jar no webapps \ myapp \ WEB-INF \ lib \ hibernatelib

Agora, eu esperaria que slf4j-api-1.5.2.jar seriam carregados automaticamente junto com hibernate Mas não o seu trabalho ... Tomcat é incapaz de encontrar os arquivos jar especificados no .mf como acima

A Pergunta:

1. Estou fazendo algo errado? ou é Tomcat?
2. Existe outra solução para este problema?

Eu já tentei \ verificou o seguinte

1. verificado para caracteres de nova linha no final do arquivo
2. Se eu colocar slf4j-api-1.5.2.jar no lib principal pasta- o erro vai away- então eu sei que não é capaz de encontrar esse arquivo jar em particular
3. Tentei, caminho absoluto relativa no arquivo de manifesto

Answer 1

O único lugar onde o atributo Class-Path no manifesto é utilizado é quando o jar contendo o manifesto é chamado como um frasco usando executável ( "java -jar theFile.jar").

Alguns recipientes de servlet parecem apoiá-lo, mas de acordo a esta mailing list pós (Desculpe, não poderia 't encontrar qualquer coisa mais authorative tão rapidamente) não é especificado na especificação também.

Tanto quanto eu entendo, aplicações web geralmente carregar suas aulas usando um único carregador de classe. "Corretamente" resolver esse problema de dependência exigiria pelo menos 2 classloaders diferentes.

solução

Um hack-ish pode ser usar JarJar ou uma ferramenta semelhante ao pacote as diferentes bibliotecas, juntamente com suas respectivas dependências.

Assim que você produzir um jar contendo Hibernate juntamente com a sua biblioteca apache-commons e outro jar contendo suportes juntamente com a sua biblioteca apache-commons. Cada cópia da biblioteca apache-commons seria movido para pacotes diferentes (possivelmente hibernate.org.apache.* e struts.org.apache.*) para resolver o problema com diferentes versões Classe.

Answer 2

Você verificou as permissões estão correctas? Também pode ser uma idéia para garantir que há uma nova linha depois que a linha última Class-Path, que me ajudou a sair mais cedo hoje!

---

Update: se o Tomcat não suporta declarações de classpath como esta, a única coisa que vem à mente envolve brincando com ClassLoaders. Pessoalmente, eu não faria isso - há todo um mundo de dor potencial por esse caminho e você provavelmente vai ter um tempo mais fácil simplesmente atualizar. Desculpe, não posso pensar em uma resposta melhor!

Answer 3

Você já tentou a última e melhor versão, de Tomcat para ver se o problema persistir? Tomcat 6 já há vários anos, e muito menos 5.5 ou 5.0 ...

Answer 4

Eu não acredito que você pode fazer isso. Tomcat não está olhando para manifesta JAR para decidir questões classpath. Ele está usando sua própria hierarquia de carregadores de classe para encontrar o que precisa, usando o que diz CLASSPATH é.

Se você quiser diferentes versões de um JAR para diferentes partes do seu aplicativo, você soa como uma pessoa que realmente precisa de OSGi . Esse é o problema é foi inventado para resolver.

Há dois JSRs concorrentes lá fora, mas Eu não sei de quaisquer implementações para a proposta módulo do Sol.

O servidor de um aplicativo que eu conheço que lhe permitirá fazer isso é servidor DM da Primavera . É um fork do Tomcat que eles estão melhorando.