Discussion :

[aperrin]

Bonjour,

Afin de standardiser un certain nombres de jar (struts, hibernate, antlr, ...) commun à différents war on envisage d'externaliser ces jar dans un répertoire (commun) et donc de les enlever des war.

Je voulais avoir des retours d'expériences vis à vis de cette stratégie, ou plus simplement d'avis sur cette méthode.

Merci d'avance pour les réponses

[hlr]

Une méthode que j'avais utilisée sur un projet (si tu utilises Tomcat, bien sûr), c'est de tout mettre dans TOMCAT_HOME/shared/lib
Là, tous tes jars seront visibles par TOUTES tes applications web
Par contre, tu auras des soucis si tu dois utiliser 2 versions d'une même librairie

[aperrin]

Nous utilisons Weblogic mais il possible d'ajouter le chemin des jar dans le classpath de chaque serveur managé. C'est en quelquesorte la solution tomcat mais configurable au niveau serveur managé. Par contre pour les serveurs managés gérant plusieurs war il sera plus compliqué de gérer deux versions d'un même war (encore que je pense qu'il est possible de donner la préférence aux jar à l'intérieur d'un war).

Ce que je me demande c'est s'il peut y avoir des impacts à faire pointer tous les war sur un même jar (donc un même fichier).
N'y a t'il pas plus de risques de goulet d'étranglement, de corruption inter war ?
Le jar est il chargé une fois en mémoire ou autant de fois que de war ?

[hlr]

Tu veux dire quoi par "corruption inter war"
Si tes war sont chargés par la même JVM, et qu'ils font référence à un même jar, ce dernier ne sera chargé qu'une seule fois. D'ailleurs, ce n'est pas le WAR qui charge le JAR mais la JVM : suivant le comportement du code, le JAR peut être chargé dès l'initialisation ou alors en cours d'exécution. Dans tous les cas, tes WAR ne font référence qu'à des classes.
Par contre, le problème de goulet d'étranglement peut exister, mais dans une moindre mesure : ceci n'existera que si la classe appelée par les WAR utilise "synchronized".

[aperrin]

Alors en fait nous avons 7 serveurs managés et 24 war (applications). Chaque serveur managé est lancé par un processus java distinct.
Le synchronised est également fonction du processus java.
Le jar sera chargé en mémoire autant de fois qu'il y a de processus java (donc de serveurs managés).
Un avantage peut donc être lié au fait que pour les jars communs il ne seront chargés qu'une fois par processus java (donc réduction de l'empreinte mémoire lié au code).

Une url sympa qui explique la mécanique de class loading sur tomcat :
http://www-igm.univ-mlv.fr/~dr/XPOSE...mcat.php?rub=9

On y voit que servlet.jar est commun à tous les war. Donc pourquoi pas d'autres jar.

Pareil pour weblogic :
http://e-docs.bea.com/wls/docs81/pro...ssloading.html

[djsnipe]

Méfies toi quand même des problèmes potentiels liées au mécanisme de chargement des classes et la hiérarchie des classLoader dans ton serveur d'application, ainsi que leur configuration, sujet au combien spécifique à un serveur J2EE et source de prises de tête (j'ai déjà donné ).

Globalement, et outre le versionning des librairies qui sera contraint, les problématiques suivantes peuvent arriver :
1) migration d'une version de lib ==> non régression sur toutes les applis
2) complexité supérieure pour les procédures d'installation du serveur, surtout si les libs changent "fréquemment". La livraison des appli n'est plus uniquement la livraison d'EAR, mais c'est aussi la modification de l'infrastructure, ici le Weblo.

De plus, je doute des gains apportés par cette factorisation des libs, quelques Mo sur le disque, surement pas grand chose en mémoire. Si l'objectif est uniquement de normaliser les versions de jar, un document décrivant les versions autorisées de chaque JAR peut être suffisant.