Mettre à niveau de Tomcat 8.0.39 à 8.0.41 entraîne des erreurs de type 'failed to scan'

Question

J'ai une application Spring Boot WAR parfaitement fonctionnelle sous Tomcat 8.0.39 sur AWS. Après avoir exécuté sudo service tomcat8 stop, mis à niveau vers Tomcat 8.0.41 via sudo yum update, et redémarré l'instance, l'application ne démarre pas. Dans le fichier journal catalina, je vois beaucoup d'exceptions de ce 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)

Voici les fichiers qui posent problème à 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

Des suggestions sur la façon de résoudre ce problème ?

---

Mise à jour #1 :

Certains des fichiers ci-dessus appartiennent à jaxws-ri. Il s'est avéré que j'avais certains (10), mais pas tous (23), des jars de JAX-WS RI 2.2.10 du répertoire lib copiés dans le répertoire lib de Tomcat. Après avoir copié les 13 jars manquants, la liste des fichiers qui posent problème à Tomcat dans le fichier journal catalina a diminué pour devenir :

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

(Les exceptions pour les fichiers ci-dessus sont répétées plusieurs fois dans le fichier journal. Il semble que le scanner soit appelé plusieurs fois au démarrage, peut-être pour numériser différents chemins de classes.)

Cela me dit qu'avec le passage de 8.0.39 à 8.0.41, Tomcat est soudain devenu très pointilleux sur la présence de tous les jars référencés, même si l'application fonctionne parfaitement bien sans beaucoup d'entre eux. De plus, Tomcat semble être très exigeant quant aux versions spécifiques de certains jars (par exemple, voir les jars jaxb-core... et jaxb-api... ci-dessus).

Maintenant, pour résoudre ce problème, je pourrais essayer de trouver tous ces jars manquants et les copier dans le répertoire lib de Tomcat. Cependant, je ne vois aucun moyen de garantir la source appropriée pour certains d'entre eux en raison de noms génériques, tels que config.jar, ou de l'absence de numéros de version.

Alors, y a-t-il un moyen d'empêcher scan.StandardJarScanner.scan de Tomcat d'être si pointilleux sur tous ces jars ?

---

Mise à jour #2 :

Il s'avère qu'une option a été ajoutée dans Tomcat 8.0.38 pour contrôler l'analyse des jars, la valeur par défaut étant true. Pour désactiver l'analyse, ajoutez la ligne suivante dans context.xml :

  ...

Pour plus de détails, voir Provide an option to disable processing of Class-Path entry in a jar's manifest file.

Answer 1

Il y avait un bug, que Tomcat 8 ignore l'en-tête Class-Path dans le fichier MANIFEST.MF d'un JAR, voir Bug 59226:

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

Ce bug a été corrigé avec Tomcat 8.0.34, mais cela a généré beaucoup d'avertissements pour des JARs non requis, voir Bug 59961:

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

Depuis Tomcat 8.0.38, vous pouvez désactiver l'analyse du fichier MANIFEST.MF, voir 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.