Discussion :

[Elendhil]

J'essaie de faire communique un serveur (non jee) avec un serveur Glassfish.
Et je voulais utilisé JMS pour la communication entre ces deux serveurs.

Es que le "client" donc le serveur non JEE qui n'a pas de broker intégré peut de lui même envoyé des messages à glassfish ? Et peut il aussi en recevoir en même temps ?

Faut-il plusieurs "Queue" , une pour que le client envoie des messages à glassfish et une autre pour le sens inverse (en mode asynchrone). Ou alors une seule queue suffit ?

Dans l'interface de glassfish , dans la configuration JMS , il y a noté type de service JMS : EMBEDED, LOCAL , REMOTE

Es qu'avec embeded une application externe peut accéder au service JMS interne à glassfish ou il faut mettre sur local ?

Quand on fait un :

Code :

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

(Queue)jndiContext.lookup("jms/queue")

Dans la chaîne de caractères il faut que ce soit le nom JNDI de la destination JMS ou alors le nom physique ?

Que faut il exactement comme librairies au client pour pouvoir communiquer avec glassfish par jms(hors container j2ee) ? Pour le moment j'ai ajouté les libs du répertoire de glassfish jusqu'à ne plus avoir de "class not found exception". J'ai mis celle-ci :

Code :

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

1
2
3
4
5
6
7
8
 
appserv-admin.jar
appserv-deployment-client.jar
appserv-ext.jar
appserv-rt.jar
imqjmsra.jar
javaee.jar
jms.jar

Que faut-il mettre comme propriétés dans le context JNDI pour enfin réussir à faire communiquer tous ça ? J'ai essayé ça:

Code :

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

1
2
3
4
5
6
7
 
Properties env = new Properties();
            env.setProperty("java.naming.factory.initial","com.sun.appserv.naming.S1ASCtxFactory");
env.setProperty("org.omg.CORBA.ORBInitialHost","localhost");
env.setProperty("org.omg.CORBA.ORBInitialPort", "7676");
 
jndiContext = new InitialContext(env);

Mais j'obtiens le message d'erreur suivant :

Code :

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

1
2
3
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl <init>
ATTENTION: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
org.omg.CORBA.COMM_FAILURE:   vmcid: SUN  minor code: 201  completed: No

Donc apparemment il tient absolument pas compte de ma propriété "org.omg.CORBA.ORBInitialPort" vu qu'il essaie de se connecter au port 3700 ...

Enfin bref si quelqu'un pouvait me donner des explications "claires" pour que je puisse ne serait ce faire qu'un hello world entre mon serveur non J2ee et glassfish ce serait cool

Pas faute d'avoir cherché des infos , mais bon on tombe que sur des messages pas forcement très claire sur des forums en anglais pour l'instant sur tous les bouts code trouvés je n'arrive à rien. Apparemment ça aurait l'air plus simple avec glassfish version 3 . Je vais peut-être essayer de changer de version. (ah oui j'utilise glassfish open source version 2.1)

Merci d'avances pour vos conseils.

[bdidier]

bonjour,

beaucoup de questions auxquelles je vais donner un lien contenant pas mal de reponses (voir pages 25, 27,29 ...dans http://dlc.sun.com/pdf/821-0028/821-0028.pdf


pour tes questions, deux approches, une "brute" et/ou propriétaire, l'autre standard pour se connecter selon la methode choisie au broker JMS ou au service de nommage de glassfish:

- l'approche "brute" et/ou propriétaire consiste a fabriquer une connection factory en utilisant les classes d'OpenMQ, de configurer les parametres nécessaires pour se connecter au broker JMS/OpenMQ tournant sur localhost:7676

un extrait de code d'un producteur / consommateur stand-alone de demo fourni avec OpenMQ 4.4 (mq/examples/applications/uclient)
(voir le post http://www.developpez.net/forums/d87...ueues-message/)

voici un petit extrait du source UniversalClient.java :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
myConnFactory = new com.sun.messaging.ConnectionFactory();
 
            Properties props = getConnFactoryConfig();
            UniversalClientUtility.setConnFactoryProperties((com.sun.messaging.ConnectionFactory) myConnFactory, props);
 
            ((com.sun.messaging.ConnectionFactory) myConnFactory).setProperty(
                        com.sun.messaging.ConnectionConfiguration.imqBrokerHostName,
                        "localhost");
 
            ((com.sun.messaging.ConnectionFactory) myConnFactory).setProperty(
                        com.sun.messaging.ConnectionConfiguration.imqBrokerHostPort,
                        "7676");

etc...

- la deuxieme approche consiste a recuperer les ressources JNDI correspondant aux objets JMS a manipuler (connection factory, queue) etc

ces ressources sont appelées "programming object" dans la doc

plusieurs methodes d'access au service de nommage sont disponibles , dont celle décrite dont ton exemple (LDAP, JNDI de type fichier)

je prefere passer les propriétés Java a la ligne de commande:
-Dorg.omg.CORBA.ORBInitialHost=localhost -Dorg.omg.CORBA.ORBInitialPort=3700

- les librairies nécessaires pour un clientOpenMQ sont, de tete, jms.jar, imq.jar
et d'autres (selon le contexte) presentes ds <glassfish-3.1_install>\mq\lib

- enfin, un bon moyen de voir le comportement du broker est de le "detacher" de glassfish, soit en mode local (glassfish demarre lebroker jms) soit en remote (mon préféré) ou le broker jms vit sa vie de fournisseur de service jms indépendamment de glassfish (un hub de type entreprise messaging)

qqs pointeurs interessants:

https://mq.dev.java.net/overview.html , le site d'OpenMQ, serveur JMS intégré a GlassFish
http://blogs.sun.com/openmessagequeue/ , un blog consacré a OpenMQ

hth,
salutations,
didier

[Elendhil]

Merci pour ton aide et toutes ces informations.

J'arrive toujours pas à recevoir les messages de mon serveur non jee sur glassfish.

Mais grâce à tes informations je sais maintenant qu'il y a un fichier de log appart de glassfish pour le broker crée dans ce répertoire:

../domain1/imq/instances/imqbroker/log.txt

Et dans ce fichier je vois que j'ai de grave problème avec mon client , enfin cela y ressemble :

[02/nov./2010:14:12:16 CET] [B1065]: Acceptation : guest@127.0.0.1:43392->jms:47489. Nombre : service=3 courtier=4
[02/nov./2010:14:12:16 CET] [B1065]: Acceptation : guest@127.0.0.1:43396->jms:47489. Nombre : service=4 courtier=5
[02/nov./2010:14:12:17 CET] [B1065]: Acceptation : guest@127.0.0.1:43398->jms:47489. Nombre : service=5 courtier=6
[02/nov./2010:14:12:17 CET] [B1065]: Acceptation : guest@127.0.0.1:43400->jms:47489. Nombre : service=6 courtier=7
[02/nov./2010:14:12:17 CET] [B1065]: Acceptation : guest@127.0.0.1:43402->jms:47489. Nombre : service=7 courtier=8
[02/nov./2010:14:12:17 CET] [B1065]: Acceptation : guest@127.0.0.1:43404->jms:47489. Nombre : service=8 courtier=9
[02/nov./2010:14:12:17 CET] [B1065]: Acceptation : guest@127.0.0.1:43406->jms:47489. Nombre : service=9 courtier=10
[02/nov./2010:14:12:17 CET] [B1065]: Acceptation : guest@127.0.0.1:43408->jms:47489. Nombre : service=10 courtier=11
[02/nov./2010:14:12:17 CET] [B1065]: Acceptation : guest@127.0.0.1:43410->jms:47489. Nombre : service=11 courtier=12
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43404->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=11
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43400->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=10
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43392->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=9
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43408->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=8
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43410->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=7
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43406->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=6
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43398->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=5
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43396->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=4
[02/nov./2010:14:13:52 CET] [B1066]: Fermeture : guest@127.0.0.1:43402->jms:47489, car "[B0061]: Le client a quitté l'application sans mettre fin aux connexions.". Nombre : service=0 courtier=3

En fait ce qui m'effraie c'est que mon serveur non jee est censé envoyer un seul et unique message dans mon test! Et la le broker log 9 connexions et déconnexions ...

Et sur le log du client , il m'affiche qu'un seul envoie de message ...

Il doit avoir un gros problème avec les threads sur mon client mais bon comprend pas pourquoi le client ne log pas tous les messages.

Bref merci pour ton aide , je vais continuer à débugger ça .

[Elendhil]

Bon résolu,

une erreur toute 'bête', je faisais ça pour envoyer un message :

Code :

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

connection.createSession(true, Session.AUTO_ACKNOWLEDGE);

Comme j'avais mis à true pour dire d'activer le mode transaction, il attendait un begin et commit , alors que moi je n'avais besoin que d'envoyer un seul message.

Donc le broker envoie bien le message mais il est jamais traité par le message drive bean car il attend d'avoir reçu tous les messages et le commit pour les traiter si je comprend bien.

Et sur le log au dessus à priori c'est tout a fait normal, c'est le pool de connexions qui est logué , par défaut , il y a 8 connexions d'activés.

[bdidier]

bonsoir,

le programme uclient que j'ai cité est disponible dans OpenMQ 4.4 et n'est plus livré avec GlassFish v3+

je continue a utilise cet outil et qqs autres comme QBrowser pour faire des micro-injections (je me suis créé un petit projet sous netbeans avec une factory de messages ad'hoc)

cela donne aussi des exemples d'envoi et de reception de message sur les topics et les queues

dans le MDB, on doit pouvoir controler le nombre de cnx du connexionPool par une propriété @ActivationConfigProperty

content de voir que ca progresse,
didier