web-dev-qa-db-fra.com

La mise à niveau de Tomcat 8.0.39 vers 8.0.41 entraîne des erreurs «échec de numérisation»

J'ai une application Spring Boot WAR fonctionnant parfaitement sous Tomcat 8.0.39 sur AWS. Après avoir émis 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 une tonne d'exceptions du 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 dont Tomcat se plaint:

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 (10), mais pas tous (23), les fichiers jars du répertoire JAX-WS RI 2.2.10 lib copiés dans le répertoire lib de Tomcat. Après avoir copié les 13 pots manquants, la liste des fichiers dont Tomcat se plaint dans le fichier journal catalina s'est réduite à:

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 invoqué à plusieurs reprises au démarrage, peut-être en analysant différents chemins d'accès aux classes.)

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

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

Alors, existe-t-il un moyen d'empêcher scan.StandardJarScanner.scan De Tomcat d'être aussi pointilleux sur tous ces pots?

Mise à jour # 2:

Il s'avère que dans Tomcat 8.0.38, un paramètre a été ajouté pour contrôler l'analyse des fichiers jar, dont la valeur par défaut est true. Pour désactiver la numérisation, ajoutez la ligne suivante dans context.xml:

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

Pour plus de détails, voir Fournir une option pour désactiver le traitement de l'entrée de chemin de classe dans le fichier manifeste d'un jar .

javafiletomcatjarupgrade
15
user1408140

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

Bogue 59226 - StandardJarScanner ignore les fichiers JAR dans l'en-tête manifeste du chemin de classe

Ce bogue a été corrigé avec Tomcat 8.0.34, mais il a généré de nombreux avertissements pour les fichiers JAR non requis, voir bogue 59961 :

Bogue 59961 - Fournit une option pour désactiver le traitement de l'entrée du chemin de classe dans le fichier manifeste d'un fichier jar

Depuis Tomcat 8.0.38, vous pouvez désactiver l'analyse du MANIFEST.MF fichier, voir The Jar Scanner Component :

scanManifest

Si la valeur est true, les fichiers Manifest de tous les fichiers JAR trouvés seront analysés pour rechercher des entrées de chemin de classe supplémentaires et ces entrées seront ajoutées aux URL à analyser. La valeur par défaut est vraie.

16
dur