Data Source et ClassLoader

Bonjour à tous,

J'utilise Tomcat dans une configuration en cluster. Le driver d'accès à la base Oracle est positionné dans common/lib et toutes les applications y ont accès. Une de mes appli souhaiterait utiliser une version différente de ce driver. Pour cela je lui ai demandé de mettre son driver dans son war, pensant qu'il serait chargé en priorité par le classloader, mais en fait pas du tout :-(
Cette application utilise une datasource définie dans son fichier server.xml.

Non seulement le driver utilisé n'est pas celui embarqué par l'application mais même quand je supprime celui dans common/lib je prends un NoClassFound exception...

J'ai relu les règles concernant les classloader dans la doc Tomcat et j'avoue ne pas très bien comprendre. Je pensais que c'était les classes dans WEB-INF/lib qui étaient chargées en priorité (je n'ai pas de delegate à true dans ma conf).

Comment puis je indiquer dans la conf Tomcat de cette application de privilégier le chargement du driver fourni par l'application ?

J'espère avoir été clair, merci d'avance pour vos réponses.

alors d'abord les drivers, c'est particulier. En effet, tu ne charge jamais directement une connection avec un driver. C'est le driver qui s'enregistre auprès de jdbc. Ensuite quand jdbc recois une string de connection (genre jdbc:oracle:thin:blablabla), il regarde dans tous les drivers enregistrés lequel peut charger la connection. Le classloader n'interviens pas là dedans. Ce qui explique que ton war n'a pas priorité dans ce cas là. En réalité c'est le dernier driver enregistré qui gagne. C'est pour ca qu'il ne faut jamais mettre les driver dans le war. Sinon le war se retrouve enregistré auprès de jdbc et au final, c'est le driver du war 1 qui pourrais se retrouvé utilisé par le war2, bonjour le meli melo ;).

Maintenant, le deuxième problème, les datasource gérées par tomcat, elle sont chargée à un niveau server et non pas à un niveau web. Ce qui fait qu'elle n'ont pas accès au classloader de ton war, et donc pas au driver, et donc impossible de charger le driver pour qu'il s'enregistre auprès de jdbc => NoClassDefFound.

Donc t'as pas le choix, faudra le mettre dans common/lib.

Merci pour ta réponse claire et complète.

Donc si je comprends bien dans une configuration en cluster, toutes les applications sont obligées de partager le même driver, ce dernier devant se trouver dans common/lib. Je trouve ce fonctionnement assez rigide et je suis assez surpris qu'il n'existe aucune solution pour contourner ce problème. Mais bon si c'est comme ça que ça fonctionne !

Citation:

---

Envoyé par tchize_

alors d'abord les drivers, c'est particulier. En effet, tu ne charge jamais directement une connection avec un driver. C'est le driver qui s'enregistre auprès de jdbc. Ensuite quand jdbc recois une string de connection (genre jdbc:oracle:thin:blablabla), il regarde dans tous les drivers enregistrés lequel peut charger la connection. Le classloader n'interviens pas là dedans. Ce qui explique que ton war n'a pas priorité dans ce cas là. En réalité c'est le dernier driver enregistré qui gagne. C'est pour ca qu'il ne faut jamais mettre les driver dans le war. Sinon le war se retrouve enregistré auprès de jdbc et au final, c'est le driver du war 1 qui pourrais se retrouvé utilisé par le war2, bonjour le meli melo ;).

Maintenant, le deuxième problème, les datasource gérées par tomcat, elle sont chargée à un niveau server et non pas à un niveau web. Ce qui fait qu'elle n'ont pas accès au classloader de ton war, et donc pas au driver, et donc impossible de charger le driver pour qu'il s'enregistre auprès de jdbc => NoClassDefFound.

Donc t'as pas le choix, faudra le mettre dans common/lib.

---

En réalité, je t'ai donné la version simplifiée. Il est possible d'avoir plusieurs drivers pour une même db avec les drivermanager de jdbc. Celui-ci, lorsqu'on lui demande un driver, va toujours regarder quelle classloader est demandeur et va retourner le driver dépendant de ce classloader là. Cependant, ca supposerais, si tu met ton driver dans WEB-INF/lib, que l'appelant est le classloader du WAR. Or, avec tomcat, les ressources du context.xml sont chargées par le classloader du serveur. On pourrais théoriquement donc envisager que d'autres serveur J2EE supporte le modèle "1 driver par war / ear". A chercher. De plus ca pose toujours de problèmes de memory leak de charger ces driver depuis le war.

Peut-être avec une datasource intégrée avec l'application ? cf. c3p0

J'ai résolu mon problème en modifiant le fichier catalina.properties. Dans ce fichier on configure notamment les répertoires utilisés par chaque classloader. Comme tu le disais la datasource étant défini au niveau server, c'est le classloader Common qui est sollicité pour récupérer la classe du driver (dans common/lib notamment). J'ai finalement rajouté le nouveau driver dans le répertoire CATALINA_BASE/shared/lib de l'appli qui voulait un driver spécifique et j'ai rajouté ce répertoire en tête de liste.

J'obtiens le résultat souhaité, vois-tu une contre-indication à cette solution ?

oui, pourquoi le mettre dans shared lib et modifier profondément le comportement de tomcat alors que common/lib fait le boulot?

shared/lib est un répertoire supposé contenir des librairies ajoutées à chaque webapp comme si elles étaient dans WEB-INF/lib. Et là t'as fait remonter ce répertoire au niveau de common/lib par ta bidouille!

Ben je l'ai mis dans le share/lib puisque dans le common/lib commun à toutes les applications se trouve celui que je ne veux pas utiliser.

De plus je ne fais que modifier le comportement d'une appli (1 appli=un tomcat dans ma conf). Et comme la datasource est chargée au niveau server et pas au niveau web (comme tu l'indiques plus haut), il ne me restait plus qu'à utiliser le share.

Citation:

---

Envoyé par tchize_

oui, pourquoi le mettre dans shared lib et modifier profondément le comportement de tomcat alors que common/lib fait le boulot?

shared/lib est un répertoire supposé contenir des librairies ajoutées à chaque webapp comme si elles étaient dans WEB-INF/lib. Et là t'as fait remonter ce répertoire au niveau de common/lib par ta bidouille!

---

le common/lib est commun à "toutes les webapps". Si t'as qu'une webapp par tomcat, je vois pas pourquoi tu met pas ton driver dans common/lib et virer l'ancien. Chaque tomcat a son propre common/lib (a priori a moins que t'aie fortement trafiqué ton tomcat)

Parce que comme je le disais plus haut, j'utilise une conf en cluster, cad n appli (avec un tomcat par appli) et pour chaque applis deux instances sur deux machines différentes. Quand tu utilises cette conf le répertoire common/lib est commun à tous les Tomcat, c'est la conf standard définie dans la doc en mode cluster.

Citation:

---

Envoyé par tchize_

le common/lib est commun à "toutes les webapps". Si t'as qu'une webapp par tomcat, je vois pas pourquoi tu met pas ton driver dans common/lib et virer l'ancien. Chaque tomcat a son propre common/lib (a priori a moins que t'aie fortement trafiqué ton tomcat)

---

la dernière fois que j'ai fait du clustering tomcat, il y avait un tomcat par à part entière par noeud, d'ou ma confusion ;)
En pratique, il vaudrait mieux, dans ton cas, créer un répertoire sépcifique plutot que de réutiliser shared/lib.