Discussion :

[zegreg]

Bonjour à tous,

J'ai un EJB qui doit utiliser des classes de Weblogic (autrement dit qui se trouvent dans les lib's du serveur). Le problème c'est que d'un Service Pack à l'autre l'ejb fonctionne ou pas. Donc ce que j'essaie de faire c'est que l'ejb puisse utiliser un jar precis de weblogic (en l'occurance webservice+ssl.jar de la sp3 ou eventuellement sp6) que je déploie dans l'ear et qu'il prenne ce jar là en priorité au lieu de celui qui se trouve dans les lib du serveur (qui lui est en sp4).

Je sais qu'il existe quelque chose dans le genre pour les app web (prefer-web-inf-classes dans le weblogic.xml) mais cela n'a évidemment pas d'effet sur les EJB. Existerait-il l'equivalent pour les ejb?

Merci d'avance

Greg

[tesla]

Normalement, il suffit de mettre le jar voulu en 1er dans le classpath.
Ton classpath doit être constitué de librairies systemes et personnelles.

Dans le script de démarrage de weblogic, il faut que tu indiques ta librairie en priorité. Supposons que ton serveur weblo utilise les jar situés dans WL_HOME="/weblogic/wlserver8.1/weblo_lib" et tes jar perso sont dans MY_HOME="/monAppli/mes_lib"
Alors tu défini ton classpath tel que :
classpath=MY_HOME:WL_HOME

[Jacques - 06]

Normalement, il suffit de mettre le jar voulu en 1er dans le classpath.

En effet seulement si tu fais cela avec des librairies Weblogic dans des versions différentes tu risques d'avoir des problèmes : dans le meilleur des cas tu n'auras plus un serveur Weblo avec le niveau de path indiqué, dans le pire des cas tu auras des problèmes de compatibilité de version de classe avec des exception de type NoSuchMethodException ou autres exceptions Runtime.

Pour ma part, toucher au classpath d'un serveur d'application est toujours une très mauvaise solution, car elle n'est pas pérenne et impacte toutes les applications déployée sur le serveur.

Une solution pourrait être de charger les classes de ton jar avec un URLClassloader pour lequel tu ne passerais pas de classloader parent afin qu'il ne trouve pas les classes du serveur d'application (recherche parent first dans l'arborescence des classloaders). Bien sûr cela ne peut fonctionner que si tes jars sont autonomes, c'est à dire qu'ils n'ont aucune dépendance vers d'autres jar du serveur d'application; Dans le cas contraire cette méthode ne pourra pas fonctionner et le problème sera beaucoup plus complexe.

Jacques Desmazières

[zegreg]

Oui je crois effectivement que le classpath est une opération risquée que je ne pourrai pas utiliser...

Je crois que je vais regarder une solution avec les class loader. Dans le weblogic-application.xml il y a moyen de faire des choses à ce niveau là (classloader-structure). Je vais essayer de voir si ça pourrais éventuellement résoudre le problème...

Merci

greg

[tesla]

En effet seulement si tu fais cela avec des librairies Weblogic dans des versions différentes tu risques d'avoir des problèmes : dans le meilleur des cas tu n'auras plus un serveur Weblo avec le niveau de path indiqué, dans le pire des cas tu auras des problèmes de compatibilité de version de classe avec des exception de type NoSuchMethodException ou autres exceptions Runtime.

Pour ma part, toucher au classpath d'un serveur d'application est toujours une très mauvaise solution, car elle n'est pas pérenne et impacte toutes les applications déployée sur le serveur.

Une solution pourrait être de charger les classes de ton jar avec un URLClassloader pour lequel tu ne passerais pas de classloader parent afin qu'il ne trouve pas les classes du serveur d'application (recherche parent first dans l'arborescence des classloaders). Bien sûr cela ne peut fonctionner que si tes jars sont autonomes, c'est à dire qu'ils n'ont aucune dépendance vers d'autres jar du serveur d'application; Dans le cas contraire cette méthode ne pourra pas fonctionner et le problème sera beaucoup plus complexe.

Jacques Desmazières

Je suis d'accord avec vous. Utiliser un classloader est plus propre. Mais lorsqu'on a une instance Weblo par appli web la tentation est grande !!
Chaque instance construit son propre classpath et le tour est joué...

[Jacques - 06]

J'en conviens parfaitement, tout dépend du contexte.

Par contre faire cela avec des lib applicatives ou tierces peut être envisagé : nous l'avons fait en prod pour remplacer le driver Oracle embarqué par Weblogic 7.0.4 qui était buggé. Mais quand il s'agit de faire cela avec des libs Weblogic le résultat est beaucoup plus aléatoire et les conséquences peuvent n'apparaître qu'en production et/ou en charge et là l'identification de la source du problème devient un cauchemard car généralement on n'arrive pas à reproduire en environnement de dev/test

Mais sur le principe nous sommes d'accord

Jacques Desmazières

[tesla]

Au fait, avez vous constaté des changements sur votre application en modifiant les paramètres Weblogic (MaxPermSize...) ?

[Jacques - 06]

Je n'ai malheureusement pas eu le temps de refaire des tirs, et partant en vacances à la fin de semaine cela repousse à Août. Mais j'ai déjà fait les modifs pour monter la valeur direct à 384, et j'ai noté tout ce que vous m'aviez dit de vérifier : de quoi m'occuper cet été (en plus de ce qui est déjà prévu : chez nous le mois d'août est un mois chargé : livraisons en septembre oblige )

Je posterai mes conclusions (ou mes questions complémentaires) dans le thread principal que tout le monde puisse en profiter.

Merci encore

Jacques Desmazières