Discussion :

[coucou78]

bonjour,

Actuellement sur notre serveur Tomcat, des contextes tournent et se connectent sans soucis à nos bases oracles 10g (et 9.2).

Nous venons de poser LE nouveau contexte est ce dernier refuse de charger les drivers jdbc ... OR si nous mettons le fichier ojdbc14.jar dans le repertoire $CATALINA_HOME/common/lib ..le driver monte !!! et uniquement si on le met ici ...

car ce fichier .jar se trouve bien sous : <context_appli>/WEB-INF/lib/
Mais il n'est pas appellé !

Ou les développeurs auraient-ils pu mettre ce chemin en dur dans leur code ???
car nous ne mettons aucune librairies sous le CATALINA_HOME (c'est une norme)

Merci de vos lumières de développeur , un chti du système qui doit debuggé le code ... java

[tchize_]

les driver sql, qu'il s'agisse d'oracle ou autre, il vaut mieux les placer dans common/lib. Pourquoi? Parce qu'il s'enregistrent automatiquement auprès de java.sql.DriverManager lors de leur chargement. Imaginons maintenant que tu aie cette structure:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
 
      Bootstrap
          |
       System
          |
       Common
      /      \
 Catalina   Shared
             /   \
        Webapp1  Webapp2 ... 
            |         |
        Ojdbc14(A) Ojdbc14(B)

Lors du chargement d'un driver jdbc, celui-ci va toujours s'enregistrer auprès de java.sql.DriverManager et une référence va se créer allant de system(contenant le package java.sql) vers Webapp1. Lors du chargement de webapp2, aucune nouvelle référence ne se créera, car le driver est déjà enregistré.
Le premier problème que l'on constate, c'est cette référence. Si on décharge Webapp1, la référence reste, empechant le garbage collect de webapp1 -> memory leak.

Deuxième problème, si Webapp2 ne fait pas appel à des datasources, mais fait directement appel à DriverManager.getConnection("jdbc:oracle:thin:@server:6969:mydb",properties), elle utilisera le driver de Webapp1, qui pourrait de surcroit foirer si webapp1 a été rechargée entre temps (le driver utilisé ferait alors partie d'un classloader déchargé, dans lequel tomcat lance délibérément des ThreadDeathException).

Plusieurs raisons donc de préférer mettre un point central avec les drivers jdbc, çà évite le mélange de contexte.

Voilà pour la théorie Dans ton cas, il faudrait plus de précisions, si tu veux absolument éviter common/lib, afin de comprendre comment résoudre autrement. Pourrais-tu nous dire quel message d'erreur tu as?

[coucou78]

voici le message d'erreur que nous avons :

Cannot load JDBC driver class 'Oracle.jdbc.driver.OracleDriver'

et ce dernier disparait si nous plaçons le ojdbc14.jar dans $CATALINA_HOME/common/lib

Ou les dev. paramétrent t'ils l'appel de cette librairie ? dans quel .xml ?
(ils ont struts , hibernate)

[tchize_]

:s pas de stacktrace? Sinon, les lib se mettent dans WEB-INF/lib d'habitude. Sans stacktrace, difficile de voir quel classloader a été impliqué.

[coucou78]

:s pas de stacktrace? Sinon, les lib se mettent dans WEB-INF/lib d'habitude. Sans stacktrace, difficile de voir quel classloader a été impliqué.

ben oui on demande que tout soit mis dans/WEB-INF/lib ... du contexte pour que chque contexte tourne dans avec ses lib propres (versionning etc)

[djalouk]

Au sein d'une architecture distribuée, j'ai des applications web fonctionnant sous Tomcat 5.5.

Aujourd'hui ces applicatifs pointent vers des bases de données Oracle 8i via une connection JDBC utilisant la librairie classes12.jar placée dans le common/lib du serveur Tomcat.

Progressivement, ces applicatifs vont pointer vers des bases Oracle 10g, nous avons choisi d'utiliser la librairie ojdbc14.jar.

Ma question est de savoir s'il est possible de faire cohabiter les deux drivers dans le common/lib du serveur Tomcat ?

Ou si c'est plus sûr que chaque webapp embarque sa propre librairie et que l'on garde le lien symbolique vers le classes12.jar ?

[tchize_]

tu pourra pas faire cohabiter les deux driver, car, malheureusement, dans l'architecture java, les driver sont enregistrés dans une place centre de java.sql. comme ce package dépend d'un classloader commun à toutes les webapp, tout chargement de driver est automatiquement visible pour toutes les webapps. Comme le choix du driver se fait par analyse de la string de connection, ce sera d'office le driver enregistré qui sera pris. classes12 ou ojdbc suivant l'ordre de chargement.

Normalement, ojdbc14 dialogue sans problème avec du oracle 8, alors pourquoi conserver ce classes12 qui date des dinausores... ?

[djalouk]

C'est justement ce dont à quoi j'ai pensé entre temps.

En effet, ojdbc14 dialogue sans problème avec du Oracle 8, on a d'ailleurs des applications qui attaquent simultanément des schémas 10g et 8i.

Y a t-il une conséquence en terme de performance si on place le driver dans le common/lib et qu'il est déjà positionné dans chaque webapp ?

Merci.

[tchize_]

retire le des webapp, ça peut poser des problèmes de classloader leak lors des redéploiement ou des stop/start de webapps

[djalouk]

Et si on l'embarque dans chaque webapp sans le mettre dans le common/lib, y a t-il des risques particuliers ?

[tchize_]

regarde mon post précédent pour les risque. Rajoute à ca que chaque webapp profitera d'un driver jdbc dont elle ne sait pas d'ou il viens. Mettre les drivers jdbc dans les webapp, je ne recommande pas.