Discussion :

[legad]

Bonjour,

Nous utilisons pour plusieurs de nos applications web (déployées sous Tomcat ou Websphere et windows ) des dlls. Or, nous rencontrons des conflits (en fait des unsatisfiedLinkError de différentes natures) quand plusieurs applis sont lancées sur ces serveurs avec des dlls qui ne sont pas forcément versionnées de la même façon (les dlls portent le même nom).
pour être plus clair, un petit schéma :
win2000/tomcat

webapp1

dlls

madll.dll

madep1dll.dll

madep1dll.dll

webapp2

dlls

madll.dll

madep1dll.dll

madep1dll.dll

selon l'appli que je lance en premier, je ne suis jamais vraiment sûr des dlls chargées.
nous avons essayé différents systèmes de chargement : le plus "flexible" consiste à faire des System.load(<chemin physique vers la dll à charger>); cela évite notamment de mettre les dlls dans le PATH de la machine (en fait le java.library.path) mais nous oblige en revanche à déclarer les dlls-dépendances au préalable.

j'essaye d'y voir un peu plus clair sur le sujet donc je suis preneur de toutes les bonnes explications / liens, etc.

Merci,

Christophe.

PS : désolé d'avoir été si long dans mon message.

[sinok]

Bah, un tomcat = une jvm.
De même pour un serveur d'application (node) Websphere (je ne parles pas du serveur websphere en lui même).

Celà veut dire que tu charges deux versions d'une même librairie au niveau de l'espace de ta JVM et de fait, bienvenue dans le DLL Hell auquel de nombreux devs windows se sont déjà frottés.

A moins de tourner sur deux JVM différentes ou de renommer les DLL je ne vois pas trop comment s'en sortir.

Ce qui grosso modo signifie deux nodes différents sous Websphere ou deux instances différentes de Tomcat.

[legad]

Merci pour ta réponse.
En fait, j'ai lu que visiblement les dlls étaient chargées pour un classloader (donc, d'après ce que je sais, pour un tomcat, 1 webapp = 1 classloader); ce qui me laisse une chance d'espérer...
pour info, ma source : http://java.sun.com/docs/books/jni/html/design.html
"each class loader maintains a set of native libraries".

Christophe.

[sinok]

Sauf que comment tu fais pour dire que le binding que tu dois utiliser est celui issu du classloader X?

Personnellement j'envisagerais beaucoup plus le fait de tourner avec deux JVM que devoir recourir à du dirty hack de ce genre là.

Et si les deux web apps sont dépendantes l'une de l'autre c'est qu'il y a probablement un problèmes d'architecture. C'est à dire que les parties communes devraient être réunies dans une partie à part, disponible sous forme de jar. Jar qui serait intégré soit dans le lib du web-inf sous tomcat. Soit dans l'EAR de livraison sous websphere.

[legad]

merci Sinok,

d'après ce que j'ai compris, le System.load() charge les dlls dans son classloader (donc celui de chacune des webapps); en principe, c'est donc assez cloisonné.

Franchement je ne suis pas sûr d'avoir tout compris là dedans, et, on est bien d'accord, ça commence à être du hack.

en fait, les 2 webapps sont bien indépendantes (chacune doit utiliser son jeu de dlls dans des versions différentes - il s'agit d'un environnement de recette où plusieurs versions d'un même produit doivent cohabiter). Donc pas de problème d'architecture.

reste la piste du multijvm; sais tu s'il est possible d'avoir un serveur type tomcat fonctionnant avec plusieurs JVMs (je dis peut être là une grosse bêtise, mais tant pis !) ?

sinon, nous avions pensé régler partiellement la question en packageant les dlls autour d'un webservice et faire en sorte que les webapps tapent dessus.

Christophe.

[sinok]

merci Sinok,

reste la piste du multijvm; sais tu s'il est possible d'avoir un serveur type tomcat fonctionnant avec plusieurs JVMs (je dis peut être là une grosse bêtise, mais tant pis !) ?

sinon, nous avions pensé régler partiellement la question en packageant les dlls autour d'un webservice et faire en sorte que les webapps tapent dessus.

Le multijvm sous Websphere c'est sans problème vu qu'un serveur d'application sous Websphere correspond à une JVM et que tu peux avoir X serveurs d'application.

Par contre pour Tomcat le seul choix est de faire tourner deux tomcat en parallèle. Par contre il est possible de faire ça avec une seule installation de tomcat, cf: http://azeditech.com/tomcat/multiple...instances.html.


Quand aux webservices, ça fait un peu usine à gaz sachant que le problème ne se reproduira pas en environnement de production.