Nightmare: Aktualisieren von Tomcat 5.5 auf 6.0

Question

Ich versuche ein perfekt laufendes Embedded Tomcat 5.5 auf Tomcat 6.0 zu aktualisieren. Ich verstehe, dass ich nur Tomcat 5.5 Gläser mit 6.0 ersetzen muss. Das habe ich gemacht.

So ersetzte ich die folgenden Gläser:

catalina-5.0.28.jar catalina-5.5.9.jar catalina-optional-5.5.9.jar 
commons-el.jar commons-modeler-1.1.0.jar jasper-compiler-jdt.jar 
jasper-compiler.jar jasper-runtime.jar jmx-5.0.28.jar jsp-api-2.0.jar 
naming-factory.jar naming-resources.jar servlet-api-2.4.jar 
servlets-default.jar tomcat-coyote.jar tomcat-http.jar tomcat-util.jar 

mit:

annotations-api.jar catalina.jar jasper.jar   tomcat-dbcp.jar 
catalina-ant.jar  el-api.jar  jsp-api.jar  tomcat-i18n-es.jar 
catalina-ha.jar  jasper-el.jar servlet-api.jar tomcat-i18n-fr.jar 
catalina-tribes.jar jasper-jdt.jar tomcat-coyote.jar tomcat-i18n-ja.jar 
tomcat-juli.jar 

Sobald ich den Server zu starten, erhalte ich die folgende Meldung in den Protokollen auf INFO-Ebene:

INFO: Starting Servlet Engine: Apache Tomcat/6.0.29 
Dec 31, 2010 6:04:18 AM org.apache.catalina.loader.WebappClassLoader validateJarFile 
INFO: validateJarFile(/usr/local/blah/blue/./WEB-INF/lib/servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class 

Basierend auf der this Erklärung, ich muss eine JAR-Datei entfernen, die einen Konflikt hat g Servlet.class. Ich schwöre bei Gott, es gibt keine andere in Konflikt stehende JAR-Datei, ich greife systemweit nach Servlet.class, es passte nur zu servlet-api.jar.

Ich habe auch heruntergeladen javaee.jar und ersetzte es durch Servlet-api.jar, zum gleichen Erfolg.

Nachdem ich viele dieser Sachen ausprobiert hatte, hatte ich nicht viel, um nach oben zu schauen, also setzte den Tomcat Logging Level auf ALL. Im Protokoll konnte ich sehen, dass es in jedem geladenen jar nach Servlet.class sucht, bis es servlet-api.jar findet und die Meldung "jar not loaded" auslöst, sobald es servlet-api.jar findet . Siehe unten:

FINE: Checking for javax/servlet/Servlet.class 
Jan 2, 2011 7:39:33 AM org.apache.catalina.loader.WebappLoader setRepositories 
FINE: Deploy JAR /WEB-INF/lib/servlet-api.jar to /usr/local/blah/blue/./WEB-INF/lib/servlet-api.jar 
Jan 2, 2011 7:39:33 AM org.apache.catalina.loader.WebappClassLoader addJar 
FINE: addJar(/WEB-INF/lib/servlet-api.jar) 
Jan 2, 2011 7:39:33 AM org.apache.catalina.loader.WebappClassLoader validateJarFile 
FINE: Checking for javax/servlet/Servlet.class 
Jan 2, 2011 7:39:33 AM org.apache.catalina.loader.WebappClassLoader validateJarFile 
INFO: validateJarFile(/usr/local/blah/blue/./WEB-INF/lib/servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class 
Jan 2, 2011 7:39:33 AM org.apache.catalina.loader.WebappLoader setRepositories 

UPDATE Ich bin in der Lage, die oben "jar nicht hinzugefügt" Fehler zu entfernen, indem Servlet-api.jar in einem separaten Ordner ablegen (wie $ CATALINA_HOME/common/lib). Doch nach wie vor die GUI zeigt Rohling (Error 404), wenn ich treffe eine URL :(. Die Log-Nachricht, wenn die URL getroffen wird weiter unten beschrieben wird. UPDATE endet

Bitte beachten Sie jedoch, dass Tomcat erfolgreich gestartet! Und Sobald ich die URL im Browser anklicke, erhalte ich eine leere Seite (dies kann nur in meinem Fall sein, ich denke, dass meine web.xml von den meisten anders ist. Andere Leute im Internet haben stattdessen Error 404.) mit Log-Anweisungen nach (auf Feinstabstufung)

Jan 2, 2011 9:40:01 AM org.apache.catalina.connector.CoyoteAdapter parseSessionCookiesId 
FINE: Requested cookie session id is 0FBA716E3F9B0147C3AF7ABAE3B1C27B 
Jan 2, 2011 9:40:01 AM org.apache.catalina.authenticator.AuthenticatorBase invoke 
FINE: Security checking request GET /login.jsp 
Jan 2, 2011 9:40:01 AM org.apache.catalina.realm.RealmBase findSecurityConstraints 
FINE: Checking constraint 'SecurityConstraint[protected]' against GET /login.jsp --> false 
Jan 2, 2011 9:40:01 AM org.apache.catalina.realm.RealmBase findSecurityConstraints 
FINE: Checking constraint 'SecurityConstraint[protected]' against GET /login.jsp --> false 
Jan 2, 2011 9:40:01 AM org.apache.catalina.realm.RealmBase findSecurityConstraints 
FINE: Checking constraint 'SecurityConstraint[protected]' against GET /login.jsp --> false 
Jan 2, 2011 9:40:01 AM org.apache.catalina.realm.RealmBase findSecurityConstraints 
FINE: Checking constraint 'SecurityConstraint[protected]' against GET /login.jsp --> false 
Jan 2, 2011 9:40:01 AM org.apache.catalina.realm.RealmBase findSecurityConstraints 
FINE: No applicable constraint located 
Jan 2, 2011 9:40:01 AM org.apache.catalina.authenticator.AuthenticatorBase invoke 
FINE: Not subject to any constraint 
Jan 2, 2011 9:40:01 AM org.apache.catalina.core.StandardWrapper allocate 
FINEST: Returning non-STM instance 

ich bin nicht sicher, ob das oben Lognachricht wichtig ist, aber ich bin für all-oute Offenbarung hier.

Eine interessante Sache, obwohl ich manuell eine Dummy-JSP-Datei erstellt, die nur "helloooo" nur außerhalb WEB-INF-Ordner enthält (keine Sicherheitsbeschränkungen für diese Datei). Diese Datei war zugänglich und könnte angezeigt werden. Aber alle meine Jsps und Klassen sind in WEB-INF (natürlich).

Krank und müde von diesem Problem, bitte hilf mir, es zu lösen. Ich habe schon 20-24 Stunden erfolglos damit verbracht.

Irgendwelche Hinweise Hinweise führt?

Answer 1

Also das Problem war wirklich: nicht den Quellcode mit den neuesten Gläsern zu kompilieren. Die auf der Maschine vorhandenen Klassen waren bereits vorhanden und wurden mit Tomcat 5.5-Gläsern und nicht mit Tomcat 6.0 kompiliert. Das Übertragen neuer Klassen löste mein Problem.

Vielen Dank an Mtraut für das Interesse an dieser Frage. Ich wünschte, ich könnte dich mehr als einmal abstimmen. :)

Answer 2

Das Servlet-api.jar wird definitiv benötigt, um Tomcat Embedded laufen zu lassen. Allerdings scheint hier ein Classloader-Problem zu bestehen. Der Classloader für die Webanwendung darf keinen direkten Zugriff auf die servlet.jar haben, sondern nur über den übergeordneten Klassenlader.

Wenn Sie nur Gläser ausgetauscht haben, dann muss es einen feinen Unterschied in den ClassLoadern von 6.0 vs. 5.5 geben, aber ich kann nicht sagen wo.

Answer 3

Tomcat 5.5 und Tomcat 6.0 weisen einige signifikante Unterschiede auf. Mein Vorschlag ist, die WAR-Dateien auf den neuen Tomcat zu verschieben, anstatt zu versuchen, den alten zu entfernen. Ein besonderer Unterschied besteht darin, dass die JAR-Dateien alle unterschiedlich organisiert sind.

Da Tomcat 6.0 offensichtlich mit allen Tomcat 6.0 JAR-Dateien geliefert wird, liegt es nahe, dass Sie keine Konflikte haben, wenn Sie nur eine frische Tomcat 6.0-Installation verwenden und dann Ihre WAR-Dateianwendungen auf den neuen Tomcat verschieben 6.

Sie werden wahrscheinlich immer noch Konflikte haben, aber Sie werden zumindest eine Variable ausgeschaltet haben, Sie werden wissen, dass Sie mit einer frischen, soliden Tomcat-Installation arbeiten, statt einer, die kaputt sein könnte oder könnte nicht gebrochen werden.

Guter Aufruf, der die Protokollierungsstufe auf ALL setzt, stellen Sie nur sicher, dass Sie alle logging.properties-Dateien erhalten, da manchmal mehrere vorhanden sein können.

http://tomcat.apache.org/tomcat-6.0-doc/logging.html

Viel Glück!

Answer 4

Das scheint seltsam - wenn Sie Ihre eigene Web-App nicht geändert haben, muss dieses Problem auch in 5.5 beendet werden.

Wie @daniel sagte, ist es Ihrer Web-App nicht erlaubt, eine Jar-Datei zu haben, die Servlet-Sachen enthält. Wenn ich das Protokoll richtig interpretiere, gibt es ein Servlet-API im Web-App-Verzeichnis. Löschen Sie Servlet-API komplett dort.

EDIT

• Was die Verzeichnisstruktur Ihrer Anwendung ist, wo die Gläser zu tun (vor allem die tomcat Gläser) leben.
• Was ist das Protokoll ausgegeben, wenn tomcat ohne den Servlet-API in Ihrem Web-App startet
• How do you "Einbetten" Kater
• Was der Classpath ist, wenn Sie Ihre App

EDIT

starten

Sie MÜSSEN die Umwelt trennen können sagen, in

 
\yourapp 
| 
+ lib 
| 
+ webapp 
    | 
    + lib (this is where your webapp lives, WITHOUT servlet-api) 

Wenn diese similiarity zu sta hat ndard JavaEE Containerstruktur - es ist NICHT durch reine Gefahr :-)

yourapp \ lib hostet Ihre Anwendung und Tomcat-Bibliotheken. Dies bildet den Klassenpfad zum Starten.

Die Datei "yourapp \ webapp \ lib" wird niemals vom Klassenpfad referenziert, sondern nur vom webapp-Klassenlader. Sie müssen den richtigen Pfad zu ihnen berücksichtigen, wenn Sie Ihren eingebauten Tomcat so konfigurieren, dass er auf diese Webanwendung verweist, da der Web-App-Loader sie möglicherweise nicht finden kann.

EDIT

Vielleicht mit etwas weniger ambitioniert als eine JSP starten. Hast du ein einfaches Test-Servlet im Einsatz?

Sie müssen darauf achten, auf welchen Webanwendungskontext Sie Ihre Anwendung bereitgestellt haben. Im Protokoll sehe ich, dass Sie den Wurzelkontext verwenden. Ist das wirklich wahr?Wenn zum Beispiel gesagt, Sie

tomcat.addWebapp("foo", appBase); 

in Ihrer Einbettung, müssen Sie anfordern/foo/Servlet, nicht/Servlet in Ihrem Browser.