Java 从 Tomcat 8.0.39 升级到 8.0.41 导致“无法扫描”错误
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/42329948/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Upgrade from Tomcat 8.0.39 to 8.0.41 results in 'failed to scan' errors
提问by user1408140
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:
我有一个 Spring Boot WAR 应用程序，可以在 AWS 上的 Tomcat 8.0.39 下完美运行。发出后sudo service tomcat8 stop，通过 升级到Tomcat 8.0.41 sudo yum update，重启实例后，应用程序没有启动。在 catalina 日志文件中，我看到了大量的异常类型：
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)
Here are the files Tomcat complains about:
以下是 Tomcat 抱怨的文件：
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?
对于如何解决这个问题，有任何的建议吗？
Update #1:
更新 #1：
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 libdirectory copied into Tomcat's libdirectory. After copying the missing 13 jars, the list of files Tomcat complains about in the catalina log file has shrunk to:
上述一些文件属于jaxws-ri. 结果是，我将 JAX-WS RI 2.2.10lib目录中的一些（10 个），但不是全部（23 个）jar复制到了 Tomcat 的lib目录中。复制丢失的 13 个 jar 后，Tomcat 在 catalina 日志文件中抱怨的文件列表已缩小为：
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.)
（上述文件的异常在日志文件中重复多次。看起来扫描器在启动时被重复调用，可能扫描不同的类路径。）
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).
这告诉我，随着从 8.0.39 到 8.0.41 的过渡，Tomcat 突然对所有引用的 jar 的存在变得非常挑剔，即使应用程序在没有很多引用的情况下也能正常工作。此外，Tomcat 似乎对某些 jar 的特定构建非常挑剔（例如，参见上面的jaxb-core...和jaxb-api...jar）。
Now, to fix this I could try to find all these missing jars and copy them to Tomcat's libdirectory. 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.
现在，为了解决这个问题，我可以尝试找到所有这些丢失的 jar 并将它们复制到 Tomcat 的lib目录中。但是，由于通用名称（例如config.jar）或缺少版本号，我认为无法确保其中一些的正确来源。
So, is there a way to prevent Tomcat's scan.StandardJarScanner.scanfrom being so picky about all these jars?
那么，有没有办法防止 Tomcatscan.StandardJarScanner.scan对所有这些罐子如此挑剔？
Update #2:
更新#2：
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:
原来在Tomcat 8.0.38中，增加了一个设置来控制jar扫描，其值默认为true. 要关闭扫描，请在 中添加以下行context.xml：
<Context>
...
<JarScanner scanManifest="false"/>
</Context>
For details, see Provide an option to disable processing of Class-Path entry in a jar's manifest file.
有关详细信息，请参阅 提供选项以禁用处理 jar 清单文件中的类路径条目。
回答by dur
There was a bug, that Tomcat 8 ignores the Class-Pathheader in the MANIFEST.MFfile of a JAR, see Bug 59226:
有一个错误，即 Tomcat 8 忽略了 JAR 文件中的Class-Path标头MANIFEST.MF，请参阅错误 59226：
Bug 59226 - StandardJarScanner ignores jars in manifest Class-path header
错误 59226 - StandardJarScanner 忽略清单类路径标头中的 jar
This bug was fixed with Tomcat 8.0.34, but it produced a lot of warnings for not required JARs, see Bug 59961:
此错误已在 Tomcat 8.0.34 中修复，但它对不需要的 JAR 产生了很多警告，请参阅错误 59961：
Bug 59961 - Provide an option to disable processing of Class-Path entry in a jar's manifest file
错误 59961 - 提供一个选项以禁用处理 jar 清单文件中的类路径条目
Since Tomcat 8.0.38 you can disable the scan of the MANIFEST.MFfile, see The Jar Scanner Component:
从 Tomcat 8.0.38 开始，您可以禁用MANIFEST.MF文件扫描，请参阅The Jar Scanner Component：
scanManifest
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.
扫描清单
如果为 true，则将扫描找到的任何 JAR 的清单文件以查找其他类路径，并将这些条目添加到要扫描的 URL 中。默认值为真。
