À propos de Message Queue 4.0

Message Queue 4.0 vise essentiellement à prendre en charge Application Server 9 PE. Il s'agit d'une version mineure comportant de nouvelles fonctionnalités, certaines améliorations et des résolutions de bogue. Cette section comprend les rubriques suivantes :

• Nouveautés de la version 4.0

• Configurations matérielle et logicielle requises

Nouveautés de la version 4.0

Message Queue 4.0 propose les nouvelles fonctionnalités suivantes :

• Modifications de l'interface pour l'exécution de l'API et du client C

• Modifications de l'interface pour l'exécution de l'API et du client Java

• Affichage d'informations à propos du magasin persistant

• Modifications du format du magasin persistant

• Administration du courtier

• Prise en charge de la persistance JDBC

• Prise en charge de SSL

• Prise en charge de JMX

• Journalisation à l'exécution client

• Notification d'événements de connexion

Ces fonctions sont décrites dans les sous-sections suivantes.

Parmi les modifications mineures mais radicales de la version 4.0, on peut souligner la désapprobation de l'option de ligne de commande pour spécifier un mot de passe. Par conséquent, vous devez stocker tous vos mots de passe dans un fichier, comme décrit à la section Option de mot de passe désapprouvée.

Modifications de l'interface pour l'exécution de l'API et du client C

La version 4.0 de Message Queue propose deux nouvelles propriétés qui s'appliqueront à tous les messages placés dans la file d'attente des messages bloqués.

• JMS_SUN_DMQ_PRODUCING_BROKER indique le courtier dans lequel le message a été créé.

• JMS_SUN_DMQ_DEAD_BROKER indique le courtier ayant marqué le message comme bloqué.

Modifications de l'interface pour l'exécution de l'API et du client Java

La version 4.0 de Message Queue propose deux nouvelles propriétés qui s'appliqueront à tous les messages placés dans la file d'attente des messages bloqués.

• JMS_SUN_DMQ_PRODUCING_BROKER indique le courtier dans lequel le message a été créé.

• JMS_SUN_DMQ_DEAD_BROKER indique le courtier ayant marqué le message comme bloqué.

Affichage d'informations à propos du magasin persistant

La sous-commande query a été ajoutée à la commande imqdbmgr. Utilisez cette sous-commande pour afficher les informations relatives au magasin persistant, notamment sa version, l'utilisateur de la base de données et la création ou non de tables de base de données.

Voici un exemple des informations affichées par la commande.

requête imqdbmgr

[04/Oct/2005:15:30:20 PDT] Utilisation du magasin persistant intégré :
        version=400
        id du courtier=Mozart1756
        url de connexion à la base de données=jdbc:oracle:thin:@Xhome:1521:mqdb
        utilisateur de la base de données=scott
Exécution en mode autonome.
Les tables de base de données ont déjà été créées.

Modifications du format du magasin persistant

La version 3.7 UR1 de Message Queue comporte deux modifications du format du magasin persistant en vue d'améliorer les performances. La première modification a été apportée au magasin de fichiers et la deuxième au magasin JDBC.

• Format des données de transaction persistantes dans le magasin de fichiers

  Le format des informations d'état de transaction stockées dans le magasin persistant basé sur les fichiers de Message Queue a été modifié pour réduire l'E/S du disque et pour améliorer les performances des transactions JMS.

• Magasin JDBC Oracle

  Dans les anciennes versions de Message Queue, le schéma de magasin pour Oracle utilisait le type de données LONG RAW pour stocker les données de messages. Dans Oracle 8, le type LONG RAW a fait place aux types de données BLOB. Message Queue 3.7 UR1 est passé au type de données BLOB en vue d'améliorer les performances et les capacités de prise en charge.

Étant donné que ces modifications influent sur la compatibilité des magasins, la version du magasin de fichiers et du magasin JDBC a été modifiée de 350 à 370 dans la version 3.7 UR1 de Message Queue.

La version 4.0 de Message Queue présente des modifications sur le magasin JDBC pour une optimisation et la prise en charge des prochaines améliorations. C'est pourquoi la version du magasin JDBC a été portée à 400. Notez que dans la version 4.0, la version du magasin persistant basé sur les fichiers demeure à 370 car celui-ci n'a pas été modifié.

Message Queue 4.0 prend en charge la conversion automatique du magasin persistant vers les versions les plus récentes du magasin basé sur les fichiers et du magasin JDBC. Au premier démarrage de imqbrokerd, si l'utilitaire détecte un ancien magasin, celui-ci sera migré vers le nouveau format, en abandonnant l'ancienne version.

• Les versions 200 et 350 du magasin basé sur les fichiers seront migrées vers le format de la version 370.

• Les versions 350 et 370 du magasin JDBC seront migrées vers le format de la version 400. (Si vous souhaitez mettre à niveau un magasin 200, il vous faudra passer par une version intermédiaire 3.5 ou 3.6.)

Si vous souhaitez annuler cette mise à niveau, vous pouvez désinstaller Message Queue 4.0, puis réinstallez la version que vous utilisiez précédemment. Étant donné que l'ancienne copie du magasin est conservée, le courtier peut l'exécuter.

Administration du courtier

L'utilitaire Command (imqcmd) fournit une nouvelle sous-commande et de nouvelles options permettant aux administrateurs de mettre le courtier en attente, de fermer le courtier après un intervalle spécifié, de détruire une connexion ou de définir des propriétés système Java (par exemple, les propriétés liées à la connexion.)

• La mise en attente du courtier place ce dernier dans un état silencieux, permettant ainsi une purge des messages avant la fermeture ou le redémarrage de celui-ci. Il est impossible de créer une nouvelle connexion vers un courtier mis en attente. Pour mettre le courtier en attente, saisissez une commande similaire à l'exemple suivant.

  imqcmd quiesce bkr -b Wolfgang:1756

• Pour fermer le courtier après un intervalle spécifié, saisissez une commande similaire à l'exemple ci-dessous. (L'intervalle de temps spécifie le nombre de secondes à attendre avant la fermeture du courtier.)

  imqcmd shutdown bkr -b Hastings:1066 -time 90

  Si vous spécifiez un intervalle de temps, le courtier journalisera un message indiquant l'heure de fermeture. Par exemple,

  Shutting down the broker in 29 seconds (29996 milliseconds)

  Alors que le courtier est en attente de fermeture, son comportement est affecté de diverses manières :

  • Les connexions JMS administratives sont encore acceptées.

  • Aucune nouvelle connexion JMS n'est acceptée.

  • Les connexions JMS existantes continuent de fonctionner.

  • Le courtier n'est pas en mesure de remplacer un autre courtier dans un cluster haute disponibilité.

  • L'utilitaire imqcmd ne s'interrompt pas, il envoie la requête de fermeture au courtier et reprend directement une activité normale.

• Pour détruire une connexion, saisissez une commande similaire à l'exemple suivant.

  imqcmd destroy cxn -n 2691475382197166336

  Utilisez la commande imqcmd list cxn ou imqcmd query cxn pour obtenir l'ID de connexion.

• Pour définir une propriété système à l'aide de imqcmd, utilisez l'option –D Ceci s'avère pratique pour définir ou ignorer des propriétés de fabrique de connexion JMS ou des propriétés système Java liées à la connexion. Par exemple :

  imqcmd list svc -secure -DimqSSLIsHostTrusted=true
  imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore 
              -Djavax.net.ssl.trustStorePassword=mytrustword

Pour de plus amples informations sur la syntaxe de la commande imqcmd, reportez-vous au Chapitre 13, Command Line Reference du Sun Java System Message Queue 4.1 Administration Guide.

Prise en charge de la persistance JDBC

Apache Derby Version 10.1.1 est désormais pris en charge en tant que fournisseur de magasin persistant compatible JDBC.

Prise en charge de SSL

À partir de la version 4.0, la valeur par défaut pour la propriété de fabrique de connexion des clients imqSSLIsHostTrusted est false. Si votre application est basée sur la valeur par défaut précédente true, vous devez reconfigurer et définir explicitement la propriété sur true.

Vous pouvez choisir de faire confiance à l'hôte lorsque le courtier est configuré pour utiliser des certificats autosignés. Dans ce cas, en plus d'indiquer que la connexion doit utiliser un service de connexions SSL (à l'aide de la propriété imqConnectionType), vous devez définir la propriété imqSSLIsHostTrusted sur true.

Par exemple, pour exécuter de manière sécurisée les applications clientes lorsque le courtier utilise des certificats autosignés, utilisez une commande similaire à l'exemple suivant.

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true <ClientAppName>

Pour exécuter de manière sécurisée l'outil d'administration imqcmd lorsque le courtier utilise des certificats autosignés, utilisez une commande similaire à l'exemple suivant.

imqcmd list svc -secure -DimqSSLIsHostTrusted=true

Prise en charge de JMX

Une nouvelle API a été ajoutée pour la configuration et le contrôle des courtiers Message Queue conformément à la spécification Java Management Extensions (JMX). À l'aide de cette API, vous pouvez configurer et contrôler les fonctions de courtier, à l'aide de programmes, depuis une application cliente Message Queue. Dans les anciennes versions de Message Queue, ces fonctions étaient uniquement accessibles à partir de la ligne de commande ou de la console d'aministration.

Cette API comporte un ensemble de Managed Beans (MBeans) JMX pour la gestion des ressources associées à Message Queue suivantes :

• courtiers de messages ;

• services de connexion ;

• connexions ;

• destinations ;

• producteurs de messages ;

• consommateurs de messages ;

• transactions ;

• clusters de courtiers ;

• journalisation ;

• machine virtuelle Java (JVM).

Ces MBeans fournissent des attributs et des opérations destinés à interroger et à manipuler, de manière synchrone, l'état des ressources sous-jacentes, ainsi que des notifications permettant à une application cliente d'écouter et de répondre, de manière asynchrone, aux modifications d'état en temps réel. À l'aide de cette API JMX, les applications clientes peuvent effectuer des tâches de configuration et de contrôle, telles que :

• définir un numéro de port du courtier ;

• définir la taille maximale de message du courtier ;

• interrompre un service de connexions ;

• définir le nombre maximal de threads pour un service de connexions ;

• obtenir le nombre actuel de connexions sur un service ;

• détruire une connexion ;

• créer une destination ;

• détruire une destination ;

• activer ou désactiver la création automatique de destinations ;

• purger tous les messages d'une destination ;

• obtenir le nombre cumulatif des messages reçus par une destination depuis le démarrage du courtier ;

• obtenir l'état actuel (en cours d'exécution ou suspendu) d'une file d'attente ;

• obtenir le nombre actuel de producteurs de messages pour une rubrique ;

• purger tous les messages d'un abonné durable ;

• obtenir la taille actuelle du tas JVM.

Pour consulter une présentation de l'API JMX ainsi que des informations de référence complètes, reportez-vous au manuel Sun Java System Message Queue 4.1 Developer’s Guide for JMX Clients .

Prise en charge du courtier : propriétés associées à JMX

Plusieurs propriétés de courtier ont été ajoutées pour la prise en charge de l' API JMX (voir le Tableau 1–3). Aucune de ces propriétés ne peut être définie à partir de la ligne de commande avec l'utilitaire Command de Message Queue (imqcmd). En revanche, elles peuvent être définies à l'aide de l'option -D de l'utilitaire Broker (imqbrokerd) ou modifiées manuellement dans le fichier de configuration de l'instance du courtier ( config.properties). En outre, certaines de ces propriétés (imq.jmx.rmiregistry.start, imq.jmx.rmiregistry.use, imq.jmx.rmiregistry.port) peuvent être définies à l'aide des nouvelles options de l'utilitaire Broker décrites dans le Tableau 1–4. Le tableau énumère chaque option, spécifie son type et décrit son utilisation.

   /jndi/rmi://hôteCourtier:portRmi
      /hôteCourtier/portCourtier/nomConnecteur

   /stub/stubRmi

La propriété imq.jmx.connector.list définit un ensemble de connecteurs JMX nommés, devant être créés au démarrage du courtier ; imq.jmx.connector.activelist spécifie les connecteurs à activer. Chaque connecteur nommé comporte son propre jeu de propriétés :

Par défaut, deux connecteurs JMX sont créés, jmxrmi et ssljmxrmi ; le premier est configuré pour ne pas utiliser le chiffrement SSL (imq.jmx.connector.jmxrmi.useSSL = false, le deuxième pour l'utiliser (imq.jmx.connector.ssljmxrmi.useSSL = true). Par défaut, seul le connecteur jmxrmi est activé au démarrage du courtier ; reportez-vous à la section Prise en charge de SSL pour les clients JMX pour obtenir des informations sur la procédure d'activation du connecteur ssljmxrmi pour des communications sécurisées.

Par souci de simplicité, de nouvelles options (Tableau 1–4) ont été ajoutées à l'utilitaire Broker de ligne de commande (imqbrokerd) en vue de contrôler l'utilisation, le démarrage et le port du registre RMI. L'utilisation et les effets de ces options sont identiques aux propriétés de courtier équivalentes, comme décrit dans le Tableau 1–3. Ce tableau énumère chaque option, spécifie sa propriété de courtier équivalente et décrit son utilisation.

Une nouvelle sous-commande (Tableau 1–5) a été ajoutée à l'utilitaire Command de ligne de commande (imqcmd) pour lister les URL de service JMX des connecteurs JMX créés et lancés au démarrage du courtier. Ces informations sont requises par les clients JMX, n'utilisant pas la classe de référence Message Queue AdminConnectionFactory, en vue d'obtenir leurs connecteurs JMX, et peuvent être également utilisées pour gérer ou contrôler Message Queue via un navigateur JMX générique, tel que la console de gestion et de contrôle Java ( jconsole).

Prise en charge de SSL pour les clients JMX

Comme nous l'avons mentionné précédemment, un courtier de messages Message Queue est configuré par défaut pour les communications non sécurisées à l'aide du connecteur JMX préconfiguré, jmxrmi. Si vous souhaitez utiliser le Secure Socket Layer (SSL ) sur certaines applications pour des communications sécurisées, vous devez activer le deuxième connecteur JMX sécurisé, ssljmxrmi. Pour ce faire, procédez comme suit :

1. Obtenez et installez un certificat signé de la même manière que pour le service de connexion ssljms, ssladmin, ou cluster , comme décrit dans le manuel Message Queue Administration Guide.

2. Installez le certificat d'autorité de certification racine dans le magasin d'approbations, si nécessaire.

3. Ajoutez le connecteur ssljmxrmi à la liste des connecteurs JMX à activer au démarrage du courtier :

   imq.jmx.connector.activelist=jmxrmi,ssljmxrmi

4. Démarrez le courtier à l'aide de l'utilitaire Broker de Message Queue( imqbrokerd), soit en lui transmettant le mot de passe du keystore dans un fichier de mots de passe, soit en saisissant celui-ci dans une ligne de commande à l'invite correspondante.

5. Par défaut, le connecteur ssljmxrmi (ou tout autre connecteur SSL) est configuré de manière à valider tous les certificats SSL de courtier qui lui sont présentés. Pour éviter cette validation (par exemple, lors de l'utilisation de certificats autosignés pour un test logiciel), définissez la propriété de courtier imq.jmx.connector.ssljmxrmi.brokerHostTrusted sur true.

Du côté client, la fabrique de connexion administrateur (AdminConnectionFactory ) doit être configurée avec un URL spécifiant ssljmxrmi comme connecteur favori :

AdminConnectionFactory  acf = new AdminConnectionFactory();
acf.setProperty(AdminConnectionConfiguration.imqAddress, "mq://myhost:7676/ssljmxrmi");

Si nécessaire, utilisez les propriétés système javax.net.ssl.trustStore et javax.net.ssl.trustStorePassword pour que le client JMX pointe vers le magasin d'approbations.

Journalisation à l'exécution client

Cette section décrit la prise en charge Message Queue 4.0 pour une journalisation à l'exécution client des événements de connexion et de ceux associés à la session.

JDK 1.4 (et versions supérieures) inclut la bibliothèque java.util.logging. Cette bibliothèque implémente une interface d'enregistrement standard pouvant être utilisée pour une journalisation basée sur les applications.

L'exécution client Message Queue utilise l'API de journalisation Java pour mettre en œuvre ses fonctions de journalisation. Vous pouvez utiliser tous les services de journalisation de J2SE 1.4 pour la configuration des activités de journalisation. Par exemple, une application peut utiliser les services de journalisation Java suivants pour configurer le mode d'envoi des informations de journalisation par l'exécution client Message Queue :

• gestionnaires de journalisation ;

• filtres de journalisation ;

• formateurs de journalisation ;

• niveaux de journalisation.

Pour plus d'informations sur l'API de journalisation Java, consultez la présentation relative à ce sujet à l'adresse suivante : http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html

Espaces de noms, niveaux et activités de journalisation

Le fournisseur Message Queue définit un ensemble d'espaces de noms de journalisation associés aux niveaux et activités de journalisation et permettant aux clients Message Queue d'enregistrer les événements de connexion et de session avec une configuration de journalisation correctement définie.

L'espace de noms de journalisation racine pour l'exécution client Message Queue est nommé javax.jms. Tous les journaux de l'exécution client Message Queue utilisent ce nom en tant qu'espace de noms parent.

Les niveaux de journalisation utilisés pour l'exécution client Message Queue sont identiques à ceux utilisés dans la classe java.util.logging.Level. Cette classe définit sept niveaux de journalisation standard, ainsi que deux paramètres supplémentaires pouvant être utilisés pour activer et désactiver la journalisation.

OFF

Désactive la journalisation.

SEVERE

Priorité la plus haute, valeur la plus élevée. Défini par l'application.

WARNING

Défini par l'application.

INFO

Défini par l'application.

CONFIG

Défini par l'application.

FINE

Défini par l'application.

FINER

Défini par l'application.

FINEST

Priorité la plus basse, valeur la plus faible. Défini par l'application.

ALL

Permet d'enregistrer tous les messages.

En règle générale, les exceptions et les erreurs survenues à l'exécution client Message Queue sont consignées dans le journal avec l'espace de noms javax.jms.

• Les exceptions levées à partir de la JVM et interceptées par l'exécution client, telles que IOException, sont consignées dans le journal avec l'espace de noms javax.jms au niveau WARNING.

• Les exceptions JMS levées à partir de l'exécution client, telles que IllegalStateException , sont consignées dans le journal avec l'espace de noms javax.jms au niveau FINER.

• Les erreurs levées à partir de la JVM et interceptées à l'exécution client, telles que OutOfMemoryError, sont consignées dans le journal avec l'espace de noms javax.jms au niveau SEVERE.

Les tableaux suivants répertorient les événements pouvant être consignés, ainsi que le niveau nécessaire à la journalisation d'événements pour les connexions JMS et pour les sessions.

Le tableau suivant décrit les niveaux de journal et les événements relatifs aux connexions.

Pour les sessions, les informations suivantes sont consignées dans l'enregistrement du journal.

• Chaque enregistrement de journal, associé à un message remis à un consommateur, inclut un ID de connexion, un ID de session et un ID de consommateur.

• Chaque enregistrement de journal, associé à un message envoyé par un producteur, inclut un ID de connexion, un ID de session, un ID de producteur et un nom de destination.

Le tableau ci-dessous décrit les niveaux de journal et les événements relatifs aux sessions.

Par défaut, le niveau du journal de sortie est hérité du JRE dans lequel l'application est exécutée. Consultez le fichier JRE_DIRECTORY/lib/logging.properties pour vérifier de quel niveau il s'agit.

Vous pouvez configurer la journalisation à l'aide de programmes ou en utilisant des fichiers de configuration. En outre, vous pouvez contrôler l'étendue de ce processus. Ces possibilités sont décrites dans les sections suivantes.

Utilisation du fichier de configuration de journalisation du JRE

L'exemple suivant présente le mode de définition des espaces de noms et des niveaux de journalisation dans le fichier JRE_DIRECTORY/lib/logging.properties, utilisé pour définir le niveau de journal de l'environnement d'exécution Java. Toutes les applications utilisant ce JRE présenteront la même configuration de journalisation. L'exemple de configuration ci-dessous définit le niveau de journalisation sur INFO pour l'espace de noms javax.jms.connection et indique que la sortie doit être écrite dans java.util.logging.ConsoleHandler .

#logging.properties file.
# « handlers » spécifie une liste des classes de gestionnaire de journaux,
# séparées par une virgule. Ces gestionnaires seront installés au 
# démarrage de la VM. Notez que ces classes doivent être comprises      
# dans le chemin de classe système.
# Par défaut, seul un ConsoleHandler (gestionnaire de consoles) est       
# configuré, affichant ainsi uniquement des messages aux niveaux INFO 
# et supérieurs.

	handlers= java.util.logging.ConsoleHandler

# Niveau de journalisation global par défaut.
# Celui-ci permet de spécifier quels types d'événements sont consignés
# dans l'ensemble des journaux. Pour tout service donné, ce niveau global
# peut être remplacé par un niveau spécifique au service.
# Notez que le ConsoleHandler dispose également d'un paramètre de
# niveau distinct pour limiter les messages imprimés dans la console.

    .level= INFO

# Seuls les messages de niveaux INFO et supérieurs sont imprimés dans la console.

    java.util.logging.ConsoleHandler.level = INFO
    java.util.logging.ConsoleHandler.formatter = 
                                    java.util.logging.SimpleFormatter

# Le journal, dont l'espace de noms est javax.jms.connection, écrira les messages
# Level.INFO dans son ou ses gestionnaires de sortie. Dans cette configuration, 
# le gestionnaire de sortie est défini sur java.util.logging.ConsoleHandler.

    javax.jms.connection.level = INFO

Utilisation d'un fichier de configuration de journalisation pour une application spécifique

Vous avez également la possibilité de définir un fichier de configuration de journalisation à partir de la ligne de commande Java utilisée pour exécuter une application. L'application utilisera alors la configuration définie dans le fichier de journalisation spécifié. Dans l'exemple ci-dessous, configFile utilise le même format que celui défini dans le fichier JRE_DIRECTORY/lib/logging.properties .

java -Djava.util.logging.config.file=configFile MQApplication

Définition de la configuration de journalisation à l'aide de programmes

Le code suivant utilise l'API java.util.logging pour consigner les événements de connexion en modifiant le niveau de journal de l'espace de noms javax.jms.connection sur FINE. Vous pouvez inclure ce type de code dans votre application pour définir la configuration de la journalisation via des programmes.

import java.util.logging.*;
//créer un gestionnaire de fichiers et l'envoyer vers le fichier mq.log
//dans le répertoire temporaire du système.

    Handler fh = new FileHandler("%t/mq.log");
    fh.setLevel (Level.FINE);

//Obtenir un journal pour le domaine « javax.jms.connection ».

    Logger logger = Logger.getLogger("javax.jms.connection");
    logger.addHandler (fh);

//le journal javax.jms.connection consigne les activités
//de niveaux FINE et supérieurs.

    logger.setLevel (Level.FINE);

Notification d'événements de connexion

Les notifications d'événements de connexion permettent à un client Message Queue d'écouter les événements de fermeture et de reconnexion et d'entreprendre l'action appropriée selon le type de notification et l'état de connexion. Par exemple, lorsqu'un basculement se produit et que le client est reconnecté à un autre courtier, une application peut vouloir nettoyer l'état de transaction correspondant et utiliser une nouvelle transaction.

Si le fournisseur Message Queue détecte un problème sérieux au niveau d'une connexion, celui-ci appelle le listener d'exceptions enregistrées de l'objet de connexion. Il appelle la méthode onException du listener et lui transmet un argument JMSException de description du problème. Le fournisseur Message Queue offre également une API de notification d'événements permettant à l'exécution client d'informer l'application des modifications de l'état de connexion. L'API de notification est définie à l'aide des éléments suivants :

• Le package com.sun.messaging.jms.notification, chargé de définir le listener d'événements et les objets d'événements de notification.

• L'interface com.sun.messaging.jms.Connection, chargée de définir les extensions vers l'interface javax.jms.Connection.

Les sections suivantes présentent les événements pouvant déclencher une notification, ainsi que la procédure de création d'un listener d'événements.

Événements de connexion

Le tableau suivant répertorie et décrit les événements pouvant être retournés par le listener d'événements.

Notez que le listener d'exceptions JMS n'est pas appelé lorsqu'un événement de connexion se produit. Celui-ci est uniquement appelé une fois que l'exécution client a épuisé ses tentatives de reconnexion. L'exécution client appelle toujours le listener d'événements avant le listener d'exceptions.

Création d'un listener d'événements

L'exemple de code suivant illustre la procédure de définition d'un listener d'événements de connexion. À chaque événement de connexion, la méthode onEvent du listener d'événements est invoquée par l'exécution client.

//créer une fabrique de connexion MQ.

com.sun.messaging.ConnectionFactory factory =
        new com.sun.messaging.ConnectionFactory();

//créer une connexion MQ.

com.sun.messaging.jms.Connection connection = 
       (com.sun.messaging.jms.Connection )factory.createConnection();

//définir un listener d'événements MQ.  Ce dernier implémente l'interface
//com.sun.messaging.jms.notification.EventListener.

com.sun.messaging.jms.notification.EventListener eListener = 
       new ApplicationEventListener();

//définir le listener d'événements sur la connexion MQ.

connection.setEventListener ( eListener );

Exemples de listener d'événements

Dans cet exemple, une application détermine que son listener d'événements consigne l'événement de connexion dans son propre système de journalisation :

la classe publique ApplicationEventListener implémente
				com.sun.messaging.jms.notification.EventListener {

public void onEvent ( com.sun.messaging.jms.notification.Event connEvent ) {
      	log (connEvent);
}
private void log ( com.sun.messaging.jms.notification.Event connEvent ) {
	      String eventCode = connEvent.getEventCode(); 
      	String eventMessage = connEvent.getEventMessage();
    	  //écrire les informations de l'événement dans le flux de sortie.
     	}
}

Configurations matérielle et logicielle requises

Pour obtenir les configurations matérielle et logicielle de la version 4.0, consultez les Notes de version de Sun Java System Application Server Platform Edition 9.