从Tomcat 8.0.39升级到8.0.41会导致“无法扫描”错误 [英] Upgrade from Tomcat 8.0.39 to 8.0.41 results in 'failed to scan' errors

查看:1064
本文介绍了从Tomcat 8.0.39升级到8.0.41会导致“无法扫描”错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在Spring上的Tomcat 8.0.39下完全可以使用Spring Boot WAR应用程序。发出 sudo service tomcat8 stop 后,通过 sudo yum update 升级到Tomcat 8.0.41,然后重启实例,应用程序无法启动。在catalina日志文件中,我看到了大量类型的例外情况:

I have a Spring Boot WAR application perfectly working under Tomcat 8.0.39 on AWS. After issuing sudo service tomcat8 stop, upgrading to Tomcat 8.0.41 through sudo yum update, and rebooting the instance, the application does not start. In the catalina log file, I see a ton of exceptions of the type:

19-Feb-2017 10:27:15.326 WARNING [localhost-startStop-1] org.apache.tomcat.util.
scan.StandardJarScanner.scan Failed to scan [file:/usr/share/java/tomcat8/javax.
annotation-api.jar] from classloader hierarchy
 java.io.FileNotFoundException: /usr/share/java/tomcat8/javax.annotation-api.jar
 (No such file or directory)

以下是Tomcat抱怨的文件:

Here are the files Tomcat complains about:

javax.annotation-api.jar
jsr181-api.jar
jaxb-api.jar
javax.xml.soap-api.jar
FastInfoset.jar
mimepull.jar
saaj-impl.jar
stax2-api.jar
woodstox-core-asl.jar
jaxb-core-2.2.10-b140802.1033.jar
jaxb-api-2.2.12-b140109.1041.jar
istack-commons-runtime-2.19.jar
txw2-2.2.10-b140802.1033.jar
hk2-core.jar
class-model.jar
config.jar
auto-depends.jar
javax.inject.jar
hk2-api.jar
osgi-resource-locator.jar
tiger-types.jar
bean-validator.jar
jtype.jar

有关如何解决此问题的任何建议吗?

Any suggestions on how to fix this?

更新#1:

上述部分文件属于 jaxws-ri 。事实证明,我有一些(10),但不是全部(23),从JAX-WS RI 2.2.10 lib 目录复制到Tomcat的 lib 目录。复制丢失的13个罐子之后,Tomcat在catalina日志文件中抱怨的文件列表缩小为:

Some of the above files belong to jaxws-ri. It turned out that I had some (10), but not all (23), of the jars from JAX-WS RI 2.2.10 lib directory copied into Tomcat's lib directory. After copying the missing 13 jars, the list of files Tomcat complains about in the catalina log file has shrunk to:

jaxb-core-2.2.10-b140802.1033.jar
jaxb-api-2.2.12-b140109.1041.jar
istack-commons-runtime-2.19.jar
txw2-2.2.10-b140802.1033.jar
hk2-core.jar
class-model.jar
config.jar
auto-depends.jar
javax.inject.jar
hk2-api.jar
osgi-resource-locator.jar
tiger-types.jar
bean-validator.jar
jtype.jar

(上述文件的例外情况在日志文件中重复多次。看起来在启动时重复调用扫描程序,可能扫描不同类路径。)

(Exceptions for the above files are repeated several times in the log file. Looks like the scanner is invoked repeatedly at startup, perhaps scanning different class paths.)

这告诉我,随着从8.0.39到8.0.41的转换,Tomcat突然变得非常挑剔所有引用的jar的存在,即使应用程序完美无缺,没有很多。此外,Tomcat似乎对某些jar的特定构建非常特别(例如,请参阅 jaxb-core ... jaxb-api .. 。上面的罐子。)

This tells me that with the transition from 8.0.39 to 8.0.41, Tomcat suddenly became very picky about the presence of all referenced jars, even though the application works perfectly fine without many of them. In addition, Tomcat appears to be very particular about specific builds of some jars (e.g. see the jaxb-core... and jaxb-api... jars above).

现在,为了解决这个问题,我可以尝试找到所有这些丢失的罐子并将它们复制到Tomcat的 lib 目录。但是,由于通用名称(例如 config.jar )或缺少版本号,我认为无法确保其中某些源的正确来源。

Now, to fix this I could try to find all these missing jars and copy them to Tomcat's lib directory. However, I see no way of assuring the proper source for some of them due to generic names, such as config.jar, or missing version numbers.

那么,有没有办法阻止Tomcat的 scan.StandardJarScanner.scan 对所有这些罐子如此挑剔?

So, is there a way to prevent Tomcat's scan.StandardJarScanner.scan from being so picky about all these jars?

更新#2:

事实证明在Tomcat 8.0.38中,添加了一个设置来控制jar扫描,其值默认为 true 。要关闭扫描,请在 context.xml中添加以下行

It turns out that in Tomcat 8.0.38, a setting was added to control jar scanning, the value of which defaults to true. To turn scanning off, add the following line in context.xml:

<Context>
  ...
  <JarScanner scanManifest="false"/>
</Context>

有关详细信息,请参阅
提供一个选项,禁止在jar的清单文件中处理Class-Path条目

For details, see Provide an option to disable processing of Class-Path entry in a jar's manifest file.

推荐答案

有一个错误,Tomcat 8忽略 Class-Path 标题/jar/manifestindex.htmlrel =noreferrer> MANIFEST.MF JAR文件,请参阅错误59226

There was a bug, that Tomcat 8 ignores the Class-Path header in the MANIFEST.MF file of a JAR, see Bug 59226:


错误59226 - StandardJarScanner忽略清单类路径头中的jar

Bug 59226 - StandardJarScanner ignores jars in manifest Class-path header

此错误已通过Tomcat 8.0.34修复,但它产生了大量不需要JAR的警告,请参阅 Bug 59961

This bug was fixed with Tomcat 8.0.34, but it produced a lot of warnings for not required JARs, see Bug 59961:


错误59961 - 提供选项在jar的清单文件中禁用Class-Path条目的处理

Bug 59961 - Provide an option to disable processing of Class-Path entry in a jar's manifest file

从Tomcat 8.0.38开始,您可以禁用<$ c的扫描$ c> MANIFEST.MF 文件,参见 Jar扫描仪组件

Since Tomcat 8.0.38 you can disable the scan of the MANIFEST.MF file, see The Jar Scanner Component:


scanManifest

scanManifest

如果为true ,将扫描找到的任何JAR的清单文件以获取其他类路径,并将这些条目添加到要扫描的URL中。默认值为true。

If true, the Manifest files of any JARs found will be scanned for additional class path entires and those entries will be added to the URLs to scan. The default is true.

这篇关于从Tomcat 8.0.39升级到8.0.41会导致“无法扫描”错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆