Discussion :

[thomine]

Bonjour,

Pour mon appli web, j'utilise des librairies sous forme de .jar.
A mon appli, je dois intégrer un module qui contient lui aussi des .jar qui sont redondants avec ceux que j'utilise déjà, mais dans des versions différentes.

Je voulais savoir comment se passait le chargement des classes d'un JAR. Si j'ai la librairie A en version 1 et en version 2, est-ce que mon serveur d'appli charge la 1ère rencontrée et ignore la 2e (comment peut-il savoir que c'est la même librairie d'ailleurs), ou est-ce qu'il la charge en ignorant les classes qui ont le même nom et package ?

A un moment j'avais essayé de faire un JAR de tout mon module (ce JAR contenait donc d'autres JAR + les classes du module) et de l'intégrer à mon appli mais j'avais des problèmes avec des classes d'API qu'il ne trouvait pas.

Merci de m'éclairer sur le chargement des fichiers JAR.

Thomas


[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

[alheim]

si tu as A1.jar et A2.jar contenant 2 versions d'un meme package com.zzz.A tu ne peux pas prédire lequel sera chargé. Peut être le premier dans le classpath ?

Au mieux tu auras une exception, au pire il prendra l'un ou l'autre et la je te laisse imaginer la suite....

[thomine]

Ok merci.

Mais alors, supposons que mon appli utilise des JAR et qu'à un moment j'ajoute un autre JAR qui contient des JAR déjà présents mais dans une version différente, cela peut poser des problèmes pour le fonctionnement de mon appli.

Faut-il regarder quels jar sont contenus dans chaque jar qu'on importe quand on a un problème et supprimer ce qui est redondant ?

Merci.

[alheim]

il y'a un ordre de chargement.

La jvm regarde d'abord au niveau du classloader de la class faisant l'import. Je pense donc qu'elle va d'abord chercher la librairie dans le jar courant.

ca ne doit donc pas poser de pb d'utiliser un jar incluant une librairie que tu as ailleurs dans une autre version.

Ceci dit, le mieux c'est davoir la bonne version partout.

Quel est ton problème exactement ?

[thomine]

J'utilise une appli web qui a déjà ses propres librairies. Dans cette appli web, je veux intégrer un module (des classes + des jar). Je voulais donc faire un JAR de tout ce module et l'intégrer dans mon appli web.

J'ai eu des messages d'erreur avec des classes qui n'étaient pas trouvées et en y regardant de plus près, j'ai vu que mon module utilisait des jar qui étaient déjà dans mon répertoire de librairie mais avec une version différente.

C'est donc une information importante si la jvm va chercher une classe en priorité dans le jar courant.

J'utilise Tomcat et Weblogic comme serveur d'application.

Merci pour ton aide.

[alheim]

la classe non trouvée existe dans un jar et pas dans l'autre ?

pourquoi inclure un jar dans ton module s'il est déja présent dans ton classpath ?

[thomine]

Si tu travailles en équipe et que quelqu'un gère ce module. Si tu lui demandes de te fournir un JAR de ce module, l'idéal serait de pouvoir utiliser ce module tel quel sans avoir à faire le tri dans les jar que t'a passés la personne.

Ayant plusieurs modules à intégrer, je voulais mieux connaitre le comportement du chargement des JAR.

[jIdJo]

C'est la technique de BEA (et d'autres) de faire un gros jar fourre tout.

Franchement arrête de faire comme cela. La librairie que tu utilises est un jar soit. Mets là dans le classpath et c'est tout. De plus choisit quelle version de cette librairie est la plus appropriée (souvent la dernière car elle est compatible ascendant) et vire les autres versions sinon ca va être la cata

[thomine]

Ok merci jIdJo.

C'est un peu ce que je pensais. Même si c'est pas le plus pratique, il va falloir que je fasse le tri des libs de tous les modules que j'intègre histoire de n'avoir qu'une et une seule version. Ca prend un peu de temps mais ça doit éviter les mauvaises surprises !

Si d'autres ont des suggestions ou leur avis à donner !
Merci.

[alheim]

quand tu travailles en equipe, il y'a différentes couches à respecter :

Certains vont travailler sur la couche présentation, d'autres sur la couche métier , d'autres sur l'infrastructure bas niveau du JDK etc.....

Lorsque qqn travaillant sur une couche te fournit un module, un jar ou une classe, il n'est pas censé te fournir aussi toutes les librairies des couches inférieures. Ce doit être un dénominateur commun.

Sinon on s'en sortirais pas. Tu imagines si tous les mecs qui font une servlet rebalancent leur version de servlet.jar dans le classpath du serveur tomcat de production ?

Restons sérieux et surtout simple.

[thomine]

Je sais bien toutes ces recommandations. Nos modules sont organisés en couche mais la répartition du travail se fait par module. Normalement, tout le monde travaille sur la même arbo et si une lib n'existe pas, elle est ajoutée pour tout le monde. Et là dans ce cas précis c'est encore plus complexe parce qu'on récupère des modules développés par une autre équipe pour un autre projet !

Bref, donc pour intégrer ce module d'un autre projet, et bien le plus "simple" était de l'intégrer comme un seul jar. Seulement, cela pose les problèmes déjà abordés. J'ai donc la confirmation avec ce post qu'il faut que j'intègre mes modules librairies par librairie pour être sur de ne pas avoir de problème de conflit de version.

En tout cas, merci pour ton aide.

[alheim]

no probleme. Pense au ta résolu si tu penses que le sujet est clos.