Java 1.5: Utilisation des imports avec JMS

La facilité en Java consiste à utiliser des imports "génériques" du genre:

import java.util.*;

ou

import javax.jms.*;

.
Autre méthode possible, laisser Eclipse réorganiser les imports du fichier source Java.

Lorsqu'on utilise Java 1.5 sur du code Java écrit pour la version 1.4 voire 1.3 du JDK, on peut rencontrer l'erreur suivante à la compilation:

reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match

En effet, les classes java.util.Queue et javax.jms.Queue existent toutes les deux ... dans le JDK et comme j'ai mis les deux imports, j'obtiens une ambiguité et la compilation échoue (ce n'est pas un warning).

Personnellement, je préfère de loin spécifier au début du fichier source Java l'intégralité des imports dont j'ai besoin. Par exemple, dans un programme d'envoi et de réception de messages JMS:

import javax.jms.QueueConnectionFactory;
import javax.jms.QueueConnection;
import javax.jms.Session;
import javax.jms.QueueSession;
import javax.jms.Queue;
import javax.jms.QueueReceiver;
import javax.jms.QueueSender;
import javax.jms.MessageListener;

import javax.jms.Message;
import javax.jms.MapMessage;

import javax.jms.JMSException;

Comme cela, non seulement je sais exactement quelles classes Java j'utilise mais je vois également en un coup d'oeil que telle classe qui pourrait me poser un problème n'est pas utilisée dans mon implémentation.

Pour une fois, incitons les développeurs à être un peu moins "lazy" que d'habitude :-)

Note: L'erreur "reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match" survient sur le programme d'exemple JMS de Sun TransactedExample.java, qui avait été écrit avant Java 1.5 évidemment.

 Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Un très ancien bug non découvert jusque là

Dans un billet où je tirais à boulets rouges sur le Copier/Coller, je mettais en évidence les inconvénients de cette pratique trop répandue.

Une fois n'est pas coutume, j'ai corrigé la semaine dernière un bug qui date d'au moins 2 ans, sur une implémentation JMS, bug qui n'avait pas été encore découvert car la plupart des utilisateurs d'applications JMS (comme les autres d'ailleurs) utilisent le Copier/Coller à outrance !

Le problème était le suivant.

Si l'on fermait le contexte JNDI juste après les appels aux lookup() JNDI des queue et queue connection factory, les connexions JMS échouaient par la suite !

C'est à dire que les connexions JMS avaient besoin du contexte JNDI pour se connecter au queue manager JMS, ce qui est une erreur.

Si ce bug n'a pas été découvert plus tôt, c'est parce que la majorité des programmes d'exemples JMS ferment le contexte JNDI en même temps que les autres ressources de l'application JMS, et non après les opérations de lookup() JNDI, ce qui serait la manière logique de faire.

Donc, pour une fois, merci au Copier/Coller !

Cela dit, de manière générale, je préconise généralement de ne pas fournir de programmes d'exemples dans les livrables d'un logiciel, car, malgré les avertissements d'usage dans les cartouches d'entête des fichiers, les utilisateurs et programmeurs utilisent trop souvent ces programmes d'exemples comme templates de base à leurs développements.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

De l’usage des programmes d’exemple

Un utilisateur m’appelle pour une question sur l’implémentation JMS dans le middleware orienté message sur lequel je travaille.

Il m’envoie un bout de code et me demande ce qui ne va pas dans son code, et pourquoi il perd des messages.

Je me rends compte que comme la majorité des exemples d’appels à un provider JMS que l’on trouve sur le net, sa session est non transactionnelle en AUTO_ACKNOWLEDGE.

Donc, si son applicatif s’arrête entre la réception du message et avant le traitement de ce dernier, le message est “perdu” puisque commité par le queue manager (AUTO_ACKNOWLEDGE !) et non traité par l’application !

Pourquoi est-ce que dès que les développeurs ont 15 lignes de code à écrire, il leur faut un exemple ?

Normalement, c’est leur métier d’écrire des programmes, ils ne devraient pas avoir des sueurs devant une page blanche !

L’exemple n’a rien de mauvais en soi, mais ce que je lui reproche, c’est l’utilisation qui en est faites la plupart du temps: si on prend un exemple pour aller plus vite dans son travail, sans prendre le (peu de) temps nécessaire pour savoir ce que l’exemple fait ou ne fait pas, au final, au lieu de gagner du temps, on en perds !

Et beaucoup plus que ce qu’on pensait gagner initialement.

Utiliser un exemple est une bonne chose, mais pas si on l’utilise comme une boite noire et surtout sans réfléchir.

Après, l’étape suivante, c’est de poster un message sur les forums: “voilà, je fais ça, ça a l’air bon mais ça ne marche pas … Est-ce quelqu’un peut m’aider ?” ….

Enfin, malheureusement, les exemples sont rarement faits pour résoudre précisément votre problème, sinon la vie serait trop belle, et puis il faut lire (un minimum) la Javadoc JMS.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
JavaMail en IMAP avec un serveur Exchange

JavaMail en IMAP avec un serveur Exchange

Accéder à un compte IMAP avec JavaMail ne pose à priori pas de problèmes.

J’étais en train de tester un bridge entre un MOM JMS et des serveurs Mails divers et variés, quand je me suis mis à tester sur Exchange, le serveur de Microsoft.

Sur Exchange, surprise à l’ouverture du Folder IMAP, la mailbox n’existe pas !
Ah bon, pourtant, j’ai un user valide et je suis connecté.

La raison de l’erreur dont la stack suit:

Exception occurred: javax.mail.MessagingException: A2 NO There is no replica for that mailbox on this server.;
nested exception is:
com.sun.mail.iap.CommandFailedException: A2 NO There is no replica for that mailbox on this server.
at com.sun.mail.imap.IMAPFolder.doCommand(IMAPFolder.java:2125)
at com.sun.mail.imap.IMAPFolder.exists(IMAPFolder.java:406)
at com.sun.mail.imap.IMAPFolder.checkExists(IMAPFolder.java:280)
at com.sun.mail.imap.IMAPFolder.open(IMAPFolder.java:779)

est que le serveur Exchange me redirigeait vers un deuxième serveur pour m’authentifier, et utilisait le premier (celui que je lui avais donné à la connexion) pour ouvrir la INBOX.

Manque de chance, la INBOX n’existe (normal) que sur le deuxième serveur (celui que j’ignorais) !

Moralité, si vous rencontrez la belle erreur “There is no replica for that mailbox on this server", pensez à mettre les traces IMAP et regardez si vous ne voyez pas passer un autre nom de serveur ; c’est celui-ci qu’il faudra utiliser.

Les développeurs de chez Microsoft pourraient étoffer le message d’erreur, par exemple: “you’ve been redirected for authentification, please check serveur name” !

Les devéloppeurs ne pensent jamais assez à l’utilisateur final …

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple