噩梦:将 Tomcat 5.5 升级到 6.0

发布于 2024-10-09 16:16:41 字数 4476 浏览 4 评论 0原文

我正在尝试将完美运行的嵌入式 Tomcat 5.5 升级到 Tomcat 6.0。我知道我需要做的就是用 6.0 替换 Tomcat 5.5 jar。 我就是这么做的。

因此,我将以下 jars: 替换

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

基于 这个解释,我需要删除一个有冲突的Servlet.class的jar文件。我向上帝发誓,没有其他冲突的 jar 文件,我在系统范围内 grep 了 Servlet.class,它只匹配 servlet-api.jar。

我还下载了 javaee.jar 并将其替换为 servlet-api.jar,效果相同。

尝试了很多这些东西后,我没有太多可看的,所以将 tomcat 日志记录级别设置为 ALL。在日志中,我可以看到它正在尝试检查正在加载的每个 jar 中的 Servlet.class,直到找到 servlet-api.jar,并在找到 servlet-api.jar 后立即抛出“jar not returned”消息。请参阅下文:

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

更新 我可以通过将 servlet-api.jar 放在单独的文件夹(如 $CATALINA_HOME/common/lib)中来删除上述“jar not added”错误。然而,当我点击 URL 时,GUI 仍然显示空白(错误 404):(。点击 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

我不确定上面的日志消息是否重要,但我在这里全面披露。

不过,一件有趣的事情是,我在 WEB-INF 文件夹外部手动创建了一个仅包含“helloooo”的虚拟 jsp 文件(该文件没有安全限制)。该文件可以访问并且可以显示。但是,我所有的 jsp 和类都在 WEB-INF 内(当然)。

厌倦了这个问题,请帮我解决它。我已经为此花费了 20-24 小时,但没有成功。

有任何指示方向提示线索吗?

I'm trying to upgrade a perfectly running embedded Tomcat 5.5 to Tomcat 6.0. I understand that all I need to do is replace Tomcat 5.5 jars with 6.0.
That's what I did.

So I replaced the following jars:

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

with:

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

As soon as I start the server, I get the following message in the logs at INFO level:

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

Based on the this explanation, I need to remove a jar file which has a conflicting Servlet.class. I swear to God, there is no other conflicting jar file, I grepped system wide for Servlet.class, it matched only servlet-api.jar.

I also downloaded javaee.jar and replaced it by servlet-api.jar, to same avail.

Having tried lot of these stuff, I did not have much to look upto, so set the tomcat logging level to ALL. In the log I could see that it is trying to check for Servlet.class in each and every jar it is loading until it finds servlet-api.jar and throws "jar not loaded" message as soon as it finds servlet-api.jar. See below:

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
I'm able to remove the above "jar not added" error by placing servlet-api.jar in a separate folder(like $CATALINA_HOME/common/lib). However the GUI still shows blank(Error 404) when I hit an URL :(. The log message when the URL is hit is described below.
UPDATE ends

Please note however, that Tomcat starts successfully!
And as soon as I hit the URL on the browser, I get blank page(this may be in my case only, I guess 'cuz of my web.xml, sorta different from most. Other people on the internet have got Error 404 instead.) with following log statements(at finest level)

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

I'm not sure if the above log message is important, but I'm for all-out disclosure here.

One interesting thing though, I manually created a dummy jsp file containing only "helloooo" just outside WEB-INF folder(no security constraints for this file). This file was accessible and could be displayed. But, all my jsp's and classes are inside WEB-INF(ofcourse).

Sick and tired of this issue, please help me solve it. I've already spent 20-24 hours on this unsuccessfully.

Any pointers directions hints leads?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

韶华倾负 2024-10-16 16:16:41

运行嵌入式 tomcat 肯定需要 servlet-api.jar。然而,这里似乎是一个类加载器问题。 Web 应用程序的类加载器不能“直接”访问 servlet.jar,只能通过其父类加载器进行访问。

如果你只替换jar,那么6.0和5.5的ClassLoaders一定有细微的差别,但我不能说在哪里。

The servlet-api.jar is definitely needed for running tomcat embedded. However, is seems to be a classloader issue here. The Classloader for the webapp must not have "direct" access to the servlet.jar, only through its parent class loader.

If you only replaced jars, then there must be a subtle difference in the ClassLoaders of 6.0 vs. 5.5, but I cannot say where.

凡间太子 2024-10-16 16:16:41

Tomcat 5.5 和 Tomcat 6.0 有一些显着差异。我的建议是将 WAR 文件移至新的 Tomcat,而不是尝试删除旧的 Tomcat。我想到的一个特别的区别是 JAR 文件的组织方式不同。

由于 Tomcat 6.0 显然附带了所有 Tomcat 6.0 JAR 文件,因此,如果您仅使用全新的 Tomcat 6.0 安装,然后将 WAR 文件应用程序移至新的 Tomcat 6,那么按理说您不会遇到任何冲突

。可能仍然存在冲突,但是您至少会消除一个变量,您会知道您正在使用全新的、可靠的 Tomcat 安装,而不是可能损坏或可能不会损坏的 Tomcat 安装。

将日志记录级别设置为 ALL 是一个不错的选择,只需确保获得所有的logging.properties 文件,因为有时可能会有多个文件。

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

你好运!

Tomcat 5.5 and Tomcat 6.0 have some significant differences. My suggestion is to move the WAR files to the new Tomcat instead of trying to gut the old one. One particular difference that comes to mind is that the JAR files are all organized differently.

Since Tomcat 6.0 obviously comes with all of the Tomcat 6.0 JAR files, it stands to reason that you won't have any conflicts if you just use a fresh Tomcat 6.0 install and then move your WAR file applications to the new Tomcat 6.

You will probably still have conflicts, but you'll at least have one variable knocked out, you'll know you're working with a fresh, solid, Tomcat installation instead of one that might be broken or might not be broken.

Good call setting the logging level to ALL, just make sure you get all of the logging.properties files as sometimes there may be more than one.

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

Good luck!

慢慢从新开始 2024-10-16 16:16:41

这看起来很奇怪 - 如果您没有更改自己的网络应用程序,那么这个问题也必须在 5.5 中退出。

正如 @daniel 所说,您的 Web 应用程序不允许有包含 servlet 内容的 jar 文件。如果我正确解释日志,则 Web 应用程序目录中有一个 servlet-api。在那里完全删除 servlet-api。

编辑

  • 您的应用程序的目录布局是什么,jar(尤其是 tomcat jar)在哪里。
  • 当 tomcat 在您的 Web 应用程序中没有 servlet-api 的情况下启动时,日志输出是什么
  • 您如何“嵌入”tomcat
  • 当您启动您的应用程序时,类路径是什么

编辑

您必须分离环境 让我们在“

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

如果这与标准 JavaEE 容器结构有相似之处” 中说- 这不是纯粹的危险:-)

yourapp\lib 托管您的应用程序和 tomcat 库。这形成了启动的类路径。

yourapp\webapp\lib jar 永远不会被类路径引用,只能被 webapp 类加载器引用。当您配置内置 tomcat 以指向此 Web 应用程序时,必须考虑它们的正确路径,否则 Web 应用程序加载器可能找不到它们。

编辑

也许从比 JSP 更不那么雄心勃勃的东西开始。您是否部署了一个简单的测试 servlet?

您必须注意已将应用程序部署到哪个 Web 应用程序上下文。在日志中我看到您使用根上下文。这是真的吗?例如,如果您

  tomcat.addWebapp("foo", appBase);

在嵌入中说,您必须在浏览器中请求 /foo/servlet,而不是 /servlet。

This seems strange - if you didn't change your own web app this issue must exit in 5.5, too.

As @daniel said, your web app is not allowed to have a jar file containing servlet stuff. If i interpret the log correctly, there is a servlet-api in the web app directory. Delete servlet-api completely there.

EDIT

  • What is the directory layout of your application, where do the jars (especially the tomcat jars) live.
  • What is the log output when tomcat starts without the servlet-api in your web app
  • How do you "embedd" tomcat
  • What's the classpath when you start your app

EDIT

You MUST separate the environment lets say in

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

If this has similiarity to standard JavaEE container structure - it is NOT by pure hazard :-)

yourapp\lib hosts your application and tomcat libraries. This forms the classpath for starting.

The yourapp\webapp\lib jars are never referenced by the classpath, only by the webapp classloader. You must take the correct path to them into account when you configure your builtin tomcat to point to this webapp, otherwise the web app loader may not find them.

EDIT

Maybe start with something less ambitioned than a JSP. Do you have a simple test servlet deployed?

You must take care to which web application context you have deployed your application. In the log i see you use the root context. Is this really true? If for example you said

  tomcat.addWebapp("foo", appBase);

in your embedding, you must request /foo/servlet, not /servlet in your browser.

近箐 2024-10-16 16:16:41

所以问题确实是:没有使用最新的 jar 来编译源代码。机器上存在的类是预先存在的,并使用 Tomcat 5.5 jar 而不是 Tomcat 6.0 进行编译。转新课程解决了我的问题。

非常感谢 mtraut 对这个问题表现出兴趣。我希望我能不止一次地给你投票。 :)

So the issue really was: not compiling the source code with latest jars. The classes present on the machine were pre-existent and compiled using Tomcat 5.5 jars and not Tomcat 6.0. Transferring fresh classes solved my problem.

Big thanks to mtraut for showing interest on this question. I wish I could up-vote you more than once. :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文