# Tomcat --- Können sich JARs in WARs beissen?



## bronks (24. Feb 2006)

Hi!

Wenn auf einem Tomcat zwei Apps laufen und beide Apps z.B. ein Paket 'util' haben, dann bekomme ich ein Problem, wenn in 'util' je eine Klasse enthalten ist, die z.B. SuperFormat heißt und eine davon einen modifizierten Code enthält. Da Tomcat nicht weiß welche Klasse zu welcher App gehört und in welchem WAR mal drin war, nimmt Tomcat einfach eine der beiden Klassen, die den gleichen Namen haben. Aus diesem Grund haut es eine von den beiden Apps auf die Nase. 

Frage: Wenn auf einem Tomcat eine alte App mit einer alten Strutsversion installiert ist, dann gibt es doch ebenfalls ein Problem, wie o.g., wenn ich eine neue App installiere, welche eine neue Strutsversion im WAR enthält?  Wie kann man das vermeiden?

Danke!

Bronks


----------



## mlange8801 (24. Feb 2006)

> Wenn auf einem Tomcat zwei Apps laufen und beide Apps z.B. ein Paket 'util' haben, dann bekomme ich ein Problem, wenn in 'util' je eine Klasse enthalten ist, die z.B. SuperFormat heißt und eine davon einen modifizierten Code enthält. Da Tomcat nicht weiß welche Klasse zu welcher App gehört und in welchem WAR mal drin war, nimmt Tomcat einfach eine der beiden Klassen, die den gleichen Namen haben. Aus diesem Grund haut es eine von den beiden Apps auf die Nase.
> 
> Frage: Wenn auf einem Tomcat eine alte App mit einer alten Strutsversion installiert ist, dann gibt es doch ebenfalls ein Problem, wie o.g., wenn ich eine neue App installiere, welche eine neue Strutsversion im WAR enthält? Wie kann man das vermeiden?



Wenn die Klassen oder Bibliotheken im WEB-INF/lib oder classes Verzeichnis deiner webapplikation liegen macht das keine Probleme.

http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
WebappX - A class loader is created for each web application that is deployed in a single Tomcat 5 instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application archive, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application archive, *are made visible to the containing web application, but to no others.*


----------



## Bleiglanz (24. Feb 2006)

Problem sind eventuell die vielen Quatsch-Archive in common/lib, z.b. file-upload, logging usw. usf

du bist immer auf der sicheren Seite, wenn du ALLE Abhängigkeiten von Drittanbietern immer in WEB-INF/lib ablegst!

(selbst wenn die schon in common/lib des Servers liegen!)


----------



## bronks (24. Feb 2006)

Danke für Eure Antworten.

Der von mir oben beschriebene Fall ist wirklich aufgetreten. Deshalb habe ich mir Gedanken über mögliche Probleme in diesem Zusammenhang gemacht.

Folgendes habe ich gemacht: In Netbeans habe ich ein Projekt kopiert und auf dieser Grundlage eine neue App gebaut. Sehr schnell habe ich bemerkt, daß sich Klassen mit gleichen Namen und gleichen Paketnamen gegenseitig behindern, wenn beide Projekt auf dem embeded Tomact deployed gehabt habe. Ich habe die Pakete umbenannt und das Problem war geregelt. So hat sich dann die Frage mit den Libs ergeben.

Das der ClassLoader nicht richtig funktioniert, wollte ich nicht glauben und habe zwei voneinander unabhängige Apps gebaut, in denen ich den o.g. Fall nachspielen wollte. Es gab keine Probleme und Konflikte. Alles war OK.

Ich nehme an, daß es irgenwelche Verwirrungen zwischen Netbeans und Tomcat durch das kopierte Projekt gab. Kann auch sein, daß das Problem beseitigt gewesen wäre, wenn ich das TomcatWorkDir gelöscht hätte, aber jetzt will ich die Umbenennerei nicht mehr rückgängig machen, um das zu testen.


----------

