Discussion :

[Iclo420]

Bonjour,

Après plusieurs jours de recherches sur le net, je me résous à soumettre mon problème ici.

En résumé : je dois intégrer un client EJB dans une application Web herbergée sous Tomcat:
- EJB tournant sous Glassfish 4
- Application web client sous Tomcat 7


Depuis un client externe de test, pas de soucis pour réaliser le lookup avec le code suivant : (Glashfish et Tomcat tournant sur la même machine)

Code :

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

1
2
3
4
5
6
7
8
9
Properties props = new Properties();
 
		props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
		props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
		props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
 
		InitialContext context = new InitialContext(props);
 
		TestInterface testInterface = (TestInterface) context.lookup("java:global/Project-ear/EJB-project/Test");

J'ai suivi les différents tuto disponible sur le net:
- Intégrer le jar gf-client.jar dans le classpath de l'application web
- Copier le répertoire "modules" de glassFish dans le répertoire parent contenant gf-client.jar

Mais j'obtiens en continu l'erreur suivante :

Code :

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

1
2
3
4
5
6
7
 
INFO: Initializing Spring root WebApplicationContext
javax.naming.NoInitialContextException: Cannot instantiate class: com.sun.enterprise.naming.impl.SerialInitContextFactory [Root exception is java.lang.ClassNotFoundException: com.sun.enterprise.naming.impl.SerialInitContextFactory]
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
        at javax.naming.InitialContext.init(InitialContext.java:242)
        at javax.naming.InitialContext.<init>(InitialContext.java:216)

Je me demande donc :
- Si il me manque une dépendance supplémentaire ?
- Si l'emplacement du répertoire module est correct et comment les chemins "../<le nom du jar>" repris dans le manifest du gf-client.jar sont-ils interprétés ? par rapport à l'emplacement du jar gf-client.jar ? par rapport à la racine du serveur tomcat ? J'ai essayé de copié le répertoire modules à différents niveau dans l'arborescence Tomcat
- Est-ce qu'il y a quelque chose de plus spécifique au niveau de la configuration de Tomcat ?


Désolé si cette question parait bête mais ça fait plusieurs jours que je cherche sans trouver quoi que ce soit qui s'y rapporte de près ou de loin sur le net.

Merci de votre aide

Cordialement

Iclo

[jeffray03]

salut,
ajoutes les jars:

Code :

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

1
2
javaee.jar
appserv-rt.jar

contenus dans le répertoire de glassfish/lib

Eric

[Iclo420]

Bonjour,

Merci beaucoup de la réponse : J'ai vérifié: les deux sont bien présents dans le classpath de l'application cliente.

Cordialement

Iclo

[jeffray03]

salut,
peux-tu nous montrer la structure de l´application cliente?
peux-tu aussi nous donner toute la trace de ton erreur?

Merci

[Iclo420]

Ca fonctionne

Il s'agissait bien d'un problème de dépendance:
En mettant tout package fournis dans GlassFish, Tomcat rencontrait une erreur au démarrage.

J'ai du passer en revue chacun des jars "gf-xxxx" qui ne font que lister d'autres jars pour contruire à la main le classpath avec les jar requis tout en évitant les jars qui pouvaient rentrer en conflit avec ceux de l'application cliente (dont je ne suis pas le développeur mais juste l'intégrateur donc sans avoir un contrôle absolu sur le classpath)


Je trouve que le système de package des jar "client" de GlassFish est très simple quand on a complètement la main et qu'on peut aller intégrer le gf-client.jar directement depuis le répertoire d'installation de GlassFish mais quand il faut le faire sans pouvoir installer GlassFish et surtout en devant intégrer tous les jar dans un même et unique répertoire qui est scanné par la webApp, c'est juste un peu plus prise de tête.

Merci beaucoup pour les deux réponses qui, mine de rien, ont achevé de me convaincre que c'était bien un problème de classpath et rien d'autre.


Bonne journée