Кошмар: Обновление Tomcat 5.5 до 6.0 - PullRequest
3 голосов
/ 02 января 2011

Я пытаюсь обновить прекрасно работающий встроенный Tomcat 5.5 до Tomcat 6.0. Я понимаю, что все, что мне нужно сделать, это заменить банки Tomcat 5.5 на 6.0. Вот что я сделал.

Поэтому я заменил следующие банки:

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

с:

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

Как только я запускаю сервер, я получаю следующее сообщение в журналах на уровне INFO:

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

Основываясь на объяснении this , мне нужно удалить файл JAR с конфликтующим Servlet.class. Клянусь Богом, другого конфликтующего файла JAR нет, я развернул всю систему для Servlet.class, он соответствует только servlet-api.jar.

Я также скачал javaee.jar и заменил его на servlet-api.jar, к тому же.

Перепробовав многие из этих вещей, мне не на что было обращать внимание, поэтому установите уровень ведения журнала tomcat на ALL. В журнале я видел, что он пытается проверить Servlet.class в каждом загружаемом банке, пока не найдет servlet-api.jar и не выдаст сообщение «jar notloaded», как только обнаружит servlet-api.jar. , Смотри ниже:

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 Я могу удалить вышеуказанную ошибку «jar not Added», поместив servlet-api.jar в отдельную папку (например, $ CATALINA_HOME / common / lib). Однако графический интерфейс пользователя по-прежнему отображается пустым (ошибка 404), когда я нажимаю на URL :(. Сообщение журнала при обращении к URL описано ниже. ОБНОВЛЕНИЕ заканчивается

Обратите внимание, что Tomcat запускается успешно! И как только я нажимаю на URL в браузере, я получаю пустую страницу (это может быть только в моем случае, я думаю, потому что мой web.xml, как-то отличается от большинства. У других людей в Интернете вместо этого появляется ошибка 404 .) со следующими логами (на самом лучшем уровне)

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

Я не уверен, что вышеприведенное сообщение журнала важно, но я за полное раскрытие здесь.

Одна интересная вещь, хотя, я вручную создал фиктивный JSP-файл, содержащий только «helloooo» только вне папки WEB-INF (без ограничений безопасности для этого файла). Этот файл был доступен и мог быть отображен. Но все мои jsp и классы находятся внутри WEB-INF (ofcourse).

Устал от этой проблемы, пожалуйста, помогите мне решить ее. Я уже потратил 20-24 часа на это безуспешно.

Какие-либо указатели направления подсказки ведет?

Ответы [ 4 ]

2 голосов
/ 02 января 2011

Tomcat 5.5 и Tomcat 6.0 имеют некоторые существенные различия. Я предлагаю переместить файлы WAR в новый Tomcat, а не пытаться удалить старый. Одно конкретное отличие, которое приходит на ум, заключается в том, что все файлы JAR организованы по-разному.

Поскольку Tomcat 6.0, очевидно, поставляется со всеми JAR-файлами Tomcat 6.0, очевидно, что у вас не возникнет никаких конфликтов, если вы просто используете свежую установку Tomcat 6.0, а затем перемещаете приложения WAR-файла в новый Tomcat 6. .

Вероятно, у вас все еще будут конфликты, но у вас будет хотя бы одна выбитая переменная, вы будете знать, что работаете со свежей, надежной установкой Tomcat вместо той, которая может быть сломана или не сломана .

Хороший вызов, установив уровень ведения журнала на ВСЕ, просто убедитесь, что вы получаете все файлы logging.properties, так как иногда их может быть несколько.

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

Удачи!

2 голосов
/ 02 января 2011

servlet-api.jar определенно необходим для запуска встроенного tomcat.Тем не менее, здесь, похоже, проблема загрузчика классов.Загрузчик классов для веб-приложения не должен иметь «прямого» доступа к servlet.jar, только через загрузчик родительского класса.

Если вы заменяете только jar-файлы, то в ClassLoaders должно быть тонкое различие 6.0 против 5.5, но я не могу сказать, где.

1 голос
/ 02 января 2011

Это кажется странным - если вы не изменили свое собственное веб-приложение, эта проблема должна выйти и в 5.5.

Как сказал @daniel, вашему веб-приложению не разрешено иметь jar-файл, содержащий содержимое сервлета. Если я правильно интерпретирую журнал, в каталоге веб-приложения есть servlet-api. Там полностью удалите сервлет-API.

EDIT

  • Каков макет каталога вашего приложения, в котором находятся файлы (особенно файлы tomcat).
  • Что такое вывод журнала, когда tomcat запускается без servlet-api в вашем веб-приложении
  • Как ты "вставляешь" кота
  • Какой путь к классу при запуске приложения

EDIT

Вы ДОЛЖНЫ отделить среду, скажем, в

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

Если это имеет сходство со стандартной структурой контейнера JavaEE - это НЕ чисто опасность: -)

yourapp \ lib содержит ваше приложение и библиотеки Tomcat. Это формирует classpath для запуска.

На jar-файлы yourapp \ webapp \ lib никогда не ссылается classpath, только загрузчик классов webapp. При настройке встроенного tomcat необходимо указать правильный путь к ним, чтобы он указывал на это веб-приложение, в противном случае загрузчик веб-приложений может их не найти.

EDIT

Может быть, начать с чего-то менее амбициозного, чем JSP. У вас установлен простой тестовый сервлет?

Вы должны позаботиться о том, в каком контексте веб-приложения вы развернули свое приложение. В журнале я вижу, вы используете корневой контекст. Это правда? Если, например, вы сказали

  tomcat.addWebapp("foo", appBase);

при встраивании вы должны запросить / foo / servlet, а не / servlet в вашем браузере.

0 голосов
/ 07 января 2011

Таким образом, проблема заключалась в следующем: не компилировать исходный код с последними jar-файлами. Классы, представленные на машине, были уже существующими и скомпилированы с использованием jar-файлов Tomcat 5.5, а не Tomcat 6.0. Перенос свежих занятий решил мою проблему.

Большое спасибо mtraut за проявленный интерес к этому вопросу. Хотел бы я проголосовать за вас не раз. :)

...