我有一个Spring Boot WAR应用程序,完全可以在AWS上的Tomcat 8.0.39下运行。在发布sudo service tomcat8 stop
后,升级到Tomcat 8.0.41到sudo yum update
,并重新启动实例,应用程序无法启动。在卡特琳娜的日志文件,我看到一吨类型的异常:从Tomcat 8.0.39升级到8.0.41会导致'扫描失败'错误
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的抱怨:
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
上的任何建议,就如何解决这一问题?
更新#1:
一些上述文件属于jaxws-ri
。事实证明,我已将JAX-WS RI 2.2.10 lib
目录中的一些(10)但不是全部(23)的目录复制到Tomcat的lib
目录中。拷贝丢失的13瓶后,在Tomcat中卡塔利娜日志文件中抱怨的文件列表已经缩小到:
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
(例外,以便将上述文件在日志文件中反复几次貌似扫描仪可能会扫描不同的类路径)
这告诉我,从8.0.39到8.0.41的转换,Tomcat突然变得非常挑剔所有引用的罐子的存在,即使应用程序工作没有很多人都很完美。另外,Tomcat似乎对某些罐子的特定构造非常特别(例如参见上面的罐子jaxb-core...
和jaxb-api...
)。
现在,为了解决这个问题,我可以尝试找到所有这些遗漏的jar并将它们复制到Tomcat的lib
目录中。但是,由于通用名称(如config.jar
)或缺少版本号,我认为没有办法确保其中某些源的正确来源。
那么,有没有办法阻止Tomcat的scan.StandardJarScanner.scan
对所有这些罐子如此挑剔?
更新#2:
事实证明,在Tomcat的8.0.38,加入一个设置来控制罐扫描,其默认为true
值。要打开扫描已关闭,添加以下行context.xml
:
<Context>
...
<JarScanner scanManifest="false"/>
</Context>
有关详细信息,请参阅 Provide an option to disable processing of Class-Path entry in a jar's manifest file。
这些文件不存在。如果Tomcat 8.0.41需要它们(而8.0.39显然没有),那么它们应该带有'yum update',但显然他们没有。 – user1408140
因此,从'rpm -ql tomcat | more'开始,看看安装的是什么,并确保这些文件实际上是丢失的,而不是意想不到的。 –