Fichiers jar indésirables dans tomcat / lib ou WEB-INF / lib

Question

Je travaille actuellement sur une application vieille de 10 ans environ. Lorsque j'ai consulté les fichiers jar associés à l'application, je peux voir un grand nombre de fichiers jar non requis et de nombreuses versions différentes du même fichier jar.

Quels sont les inconvénients d'avoir des bocaux indésirables dans lib. Quel est le moyen facile de les trouver et de les supprimer?

Answer 1

Vous pourriez avoir des problèmes si un chargeur de classes décide de charger des classes à partir d'une version de fichier jar différente de celle à laquelle vous vous attendiez. Ce genre de problèmes est généralement difficile à suivre. Le serveur examinera les fichiers jars dans un ordre spécifique (alphabétiquement par nom de fichier?) Et utilisera la première classe / ressource correspondante trouvée. Il n'y a probablement aucune garantie que la dernière version d'un fichier jar soit examinée en premier.

Je ne connais aucun outil permettant de savoir quels bocaux sont inutilisés. Cela peut être impossible en général, à cause de la réflexion, mais un certain degré de contrôle automatique devrait être possible, du moins en théorie.

Supprimer le fichier JAR inutilisé par essais et erreurs est problématique si vous ne disposez pas de bons tests unitaires, ce qui, je le doute, existe dans votre application vieille de plusieurs décennies. Il peut toujours y avoir quelques rares cas d’erreur qui dépendent uniquement de l’ancienne version du fichier jar que vous venez de supprimer.

Answer 2

Je suggère que si vos applications fonctionnent, laissez les bocaux tels quels. Il sera très gênant, voire impossible, de savoir quels fichiers JAR sont réellement récupérés par le chargeur de classes. (Bien sûr, ne déployez pas de nouvelles applications).

Vous pouvez trouver les packages qu'un fichier jar contient en utilisant JarAnalyzer . Cela vous donnera une idée des doublons et vous pourrez commencer à supprimer les anciennes versions des fichiers jar. Toutefois, cette procédure doit être effectuée à la main et par essais. De même, le même package peut être contenu dans deux fichiers JAR avec des noms différents et sans informations de version.

Comme déjà dit, le fait d’avoir différentes versions du même bocal pourrait faire des ravages. Vous ne pouvez pas savoir quelle version sera réellement utilisée et quels conflits elle apportera à cette application ou à une autre. C'est pourquoi vous ne devez jamais utiliser le dossier partagé de Tomcat pour les fichiers JAR d'applications. Si vous vous trouvez dans une situation où de nombreux fichiers JAR sont placés dans le dossier partagé, évitez d’utiliser ce serveur pour de nouvelles applications.

Answer 3

Par fichiers jar indésirables dans votre application, voulez-vous dire qu'ils sont générés dans le cadre de votre processus de compilation et de construction à chaque fois? Si tel est le cas, il se peut que ce soit les scripts de construction que vous souhaitez nettoyer.

Si vous vous référez à l'environnement de déploiement réel, tout nettoyage doit être effectué avec beaucoup de soin. Pourquoi ne pas essayer de recommencer dans un nouvel environnement de test avec une installation tomcat propre et les derniers exécutables de la version déployés? Voyez si cela fonctionne bien, et si c'est le cas, les bocaux supplémentaires sont peut-être inutiles.

En ce qui concerne les inconvénients, je ne vois rien en dehors de la taille du fichier de votre déploiement.

Answer 4

Comment pouvez-vous choisir les bocaux qui ne seront pas utilisés ?

Je suggérerais de faire de ce programme un QA complet nécessitant des changements. Vous ne savez pas si le code choisi dans l'ensemble des fichiers jars imite une implémentation erronée qui fait surface si vous supprimez un " obsolete " pot.