Conseils pour la résolution des incidents liés au client d'application

Procédez au débogage de certains problèmes courants du client d'application Java™ Platform, Enterprise Edition (Java EE) à l'aide de ce manuel d'identification et de résolution des incidents. Examinez les entrées de trace de l'une des exceptions du client d'application Java EE, puis localisez cette exception dans le guide.

Certaines des erreurs indiquées dans le guide sont fournies à titre d'exemples et celles que vous rencontrerez seront peut-être différentes. Il sera peut-être utile réexécuter la commande launchClient en spécifiant l'option -CCverbose=true. Cette option fournit des informations supplémentaires lors de l'initialisation de l'environnement d'exécution (runtime) du client d'application Java EE.

Erreur : java.lang.NoClassDefFoundError

Explication Causes possibles Action recommandée
Cette exception est émise lorsque le code Java ne peut pas charger la classe spécifiée.
  • Classe non valide ou inexistante.
  • Problème de chemin de classes
  • Problème lié au manifeste
Vérifiez si la classe spécifiée existe dans un fichier Java Archive (JAR) faisant partie des éléments de votre fichier EAR. Si c'est le cas, assurez-vous que le chemin d'accès à cette classe est correct. Par exemple, si vous obtenez l'exception :
java.lang.NoClassDefFoundError: 
WebSphereSamples.HelloEJB.HelloHome
vérifiez que la classe HelloHome existe dans l'un des fichiers JAR figurant dans votre fichier EAR. Si elle existe, assurez-vous que son chemin est bien WebSphereSamples.HelloEJB.
Si la classe et son chemin sont corrects, il s'agit d'un problème de définition du chemin de classes. La cause la plus probable est que le fichier JAR de la classe en cause ne figure pas dans le manifeste des fichiers JAR du client. Pour le vérifier, effectuez les tâches suivantes :
  1. Ouvrez votre fichier EAR avec un outil d'assemblage, et sélectionnez le client d'application.
  2. Ajoutez les noms des autres fichiers JAR contenus dans le fichier EAR à la zone Chemin d'accès aux classes.
Cette exception est généralement provoquée par l'absence d'un nom de module Enterprise Java (EJB) dans la zone Chemin d'accès aux classes.

Si vous avez plusieurs noms de fichiers JAR à entrer dans la zone Chemin d'accès aux classes, séparez-les par des espaces.

Si le problème persiste, cela signifie qu'une classe est chargée à partir du système de fichiers plutôt qu'à partir du fichier EAR. Cette erreur est difficile à déboguer, car la classe en cause n'est pas celle qui est spécifiée dans l'exception. Une autre classe est chargée à partir du système de fichiers avant celle qui est spécifiée dans l'exception. Pour corriger cette erreur, vérifiez les chemins d'accès aux classes spécifiés avec l'option -CCclasspath, ainsi que ceux configurés avec l'outil de configuration des ressources du client d'application.

[z/OS]Vous pouvez également utiliser l'outil de scriptage des ressources du conteneur.

Recherchez les classes qui existent également dans le fichier EAR. Vous devez éliminer toute situation où l'une des classes figure dans le système de fichiers et non dans le fichier EAR. Pour ce faire, supprimez les entrées adéquates des chemins d'accès aux classes ou ajoutez-y les fichiers JAR et les classes du fichier EAR au lieu de les désigner à partir du système de fichiers.

Si vous utilisez le paramètre -CCclasspath ou les chemins d'accès aux classes de la ressource dans l'outil, et si vous avez configuré plusieurs fichiers JAR ou classes, vérifiez qu'ils sont séparés par le caractère approprié pour votre système d'exploitation. Contrairement au champ Chemin d'accès aux classes, ces champs fonctionnent avec le caractère de séparation propre à la plateforme utilisée.

[AIX][HP-UX][Linux][Solaris]Le caractère de séparation est le signe deux-points.

[Windows]Le caractère de séparation est le signe deux-points.

Conseil : La variable système classpath n'est pas utilisée par le contexte d'exécution du client d'application si vous utilisez l'outil launchClient (fichier .bat ou shell, selon la plateforme). Dans ce cas, la variable système classpath ne provoque pas ce problème. Cependant, si vous chargez directement la classe launchClient, la recherche doit aussi prendre en compte la variable système classpath.

Erreur : com.ibm.websphere.naming.CannotInstantiateObjectException

Erreur : com.ibm.websphere.naming.CannotInstantiateObjectException: Une exception est survenue lors de la tentative d'extraction d'une instance de l'objet de référence spécifié. [L'exception racine est javax.naming.NameNotFoundException: xxxxxxxxxx]

Explication Causes possibles Action recommandée
Cette exception se produit en cas de recherche d'un objet qui n'est pas installé sur le serveur hôte. Votre programme peut rechercher le nom dans l'espace de nom JNDI (Java Naming and Directory Interface) local du client, mais il reçoit une exception NameNotFoundException car l'objet correspondant n'est pas situé sur le serveur hôte. Un exemple typique de ce genre de problème est la recherche d'un composant EJB qui n'est pas installé sur le serveur hôte auquel vous accédez. Cette exception peut aussi se produire si le nom JNDI que vous avez configuré dans votre module client d'application ne correspond pas au nom JNDI de la ressource sur le serveur hôte.
  • Serveur hôte incorrect appelé.
  • Ressource non définie.
  • Ressource non installée.
  • Serveur d'applications non démarré.
  • Configuration JNDI non valide.
Si vous avez accédé au mauvais serveur, exécutez à nouveau la commande launchClient avec le paramètre -CCBootstrapHost en vous assurant que le nom du serveur hôte est correct. Si vous avez accédé au serveur hôte correct, utilisez la commande dumpnamespace du produit pour obtenir le listage de l'espace de noms JNDI de ce serveur. Si le nom de l'objet en cause ne figure pas dans ce listage, soit la ressource n'est pas installée sur le serveur hôte, soit le serveur d'applications correct n'est pas lancé. Si vous déterminez que la ressource est déjà installée et démarrée, le nom JNDI spécifié dans votre client d'application ne correspond pas au nom JNDI global défini sur le serveur hôte. Utilisez un outil d'assemblage pour comparer la valeur des liaisons JNDI du nom de l'objet en cause dans l'application client à la valeur de liaisons JNDI de l'objet dans l'application de serveur hôte. Les valeurs doivent concorder.

Erreur : javax.naming.ServiceUnavailableException

Erreur : javax.naming.ServiceUnavailableException : Un échec de communication est survenu lors de la tentative d'extraction d'un contexte initial à l'aide de l'URL du fournisseur : "iiop://[invalidhostname]". Vérifiez que les informations relatives à l'hôte et au port sont correctes et que le serveur identifié par l'URL du fournisseur correspond à un serveur de noms actif. Si aucun numéro de port n'est spécifié, le port par défaut numéro 2809 est utilisé. Les autres causes de cette erreur peuvent provenir de l'environnement réseau ou de la configuration réseau du poste de travail. L'exception racine est org.omg.CORBA.INTERNAL : JORB0050E : Dans Profile.getIPAddress(), InetAddress.getByName[invalidhostname] a généré une exception UnknownHostException. Code mineur : 4942F5B6 terminé : Peut-être

Explication Causes possibles Action recommandée
Cette exception se produit lorsque vous spécifiez un nom de serveur hôte non valide.
  • Serveur hôte incorrect appelé.
  • Nom de serveur hôte non valide.
Exécutez de nouveau la commande launchClient et assurez-vous que le nom du serveur hôte figure correctement dans le paramètre -CCBootstrapHost.

Erreur : javax.naming.CommunicationException

Erreur : javax.naming.CommunicationException : Impossible d'extraire un contexte initial en raison d'un échec de communication. Aucune URL de fournisseur n'ayant été spécifiée, l'hôte et le port de démarrage d'un ORB existant ont été utilisés ou une instance d'ORB a été créée et initialisée à l'aide de l'hôte et du port de démarrage par défaut, "localhost" et 2809. Vérifiez que l'hôte et le port de démarrage de l'ORB sont bien résolus en un serveur de noms actif. L'exception racine est org.omg.CORBA.COMM_FAILURE : WRITE_ERROR_SEND_1 code mineur : 49421050 terminé : Non

Explication Causes possibles Action recommandée
Explication : Cette exception se produit lorsque vous exécutez launchClient en désignant un serveur hôte sur lequel Application Server n'est pas lancé. Vous la recevez également si vous spécifiez un nom de serveur hôte non valide. Cette situation se produit si vous ne spécifiez pas de nom de serveur hôte lorsque vous exécutez la commande launchClient. Dans ce cas, launchClient considère que l'hôte par défaut est l'hôte local, car WebSphere Application Server ne connaît pas le nom de votre serveur hôte. Ce comportement par défaut est appliqué uniquement si vous exécutez le client sur la machine sur laquelle WebSphere Application Server est installé.
  • Serveur hôte incorrect appelé.
  • Nom de serveur hôte non valide.
  • Référence non valide à localhost
  • Serveur d'applications non démarré.
  • Port d'amorçage non valide.
Si vous n'avez pas désigné le serveur hôte correct, exécutez à nouveau la commande launchClient en spécifiant le nom de votre serveur hôte avec le paramètre -CCBootstrapHost. Sinon, démarrez le serveur d'applications WebSphere sur le serveur hôte et exécutez à nouveau la commande launchClient.
[Windows]

Erreur : javax.naming.CommunicationException

Message d'erreur : javax.naming.CommunicationException: Impossible d'obtenir les utilisateurs correspondant au modèle wasuser6 en raison de l'exception suivante javax.naming.CommunicationException: échec de la liaison simple : emplacement_serveur. L'exception racine est javax.net.ssl.SSLHandshakeException: L'hôte distant a fermé la connexion pendant l'établissement de la liaison.

Explication Causes possibles Action recommandée
Cette exception se produit lorsque vous activez la sécurité administrative, applicative et Java 2 à l'aide du registre d'utilisateurs LDAP. Le gestionnaire de déploiement redémarre, mais vous ne pouvez pas vous connecter à la console d'administration. Le message d'erreur apparaît dans le fichier SystemOut.log.
  • L'option SSL activé est cochée dans le panneau de configuration du registre LDAP autonome.
  • Il y a une erreur dans le numéro de port ou le nom d'hôte LDAP. Le certificat du serveur LDAP présente une erreur ou a expiré sur le serveur LDAP.
  • L'organisme de certification n'est pas importé dans WebSphere Application Server, ou il présente une erreur.
  • La configuration Secure Sockets Layer (SSL) est erronée.
  • Il y a un incident réseau.
Décochez l'option SSL activé et essayez d'établir une nouvelle connexion. L'option SSL activé indique s'il est nécessaire de protéger les connexions entre le plug-in WebSphere Application Server et le serveur d'applications à l'aide du protocole SSL. Par défaut, le protocole SSL n'est pas utilisé.

Erreur : javax.naming.NameNotFoundException

Erreur : javax.naming.NameNotFoundException: Name comp/env/ejb introuvable dans le contexte "java :"

Explication Causes possibles Action recommandée
Cette exception est émise lorsque Java ne peut pas localiser le nom spécifié dans l'espace de nom JNDI local.
  • Aucune information de liaison pour le nom spécifié.
  • Informations de liaison incorrectes du nom spécifié.
  • Chargeur de classe incorrect utilisé pour charger l'une des classes du programme.
  • Une référence de ressource n'inclut pas d'informations sur la configuration du client
  • Un conteneur client du gestionnaire de déploiement tente d'utiliser des extensions d'entreprise (non pris en charge)

Ouvrez le fichier EAR avec un outil d'assemblage et contrôlez les liaisons définies pour le nom en cause. Vérifiez qu'elles sont correctes. Si vous utilisez les références de ressource, ouvrez le fichier EAR à l'aide de l'outil de configuration des ressources du client d'application, et vérifiez que la référence de ressource contient bien des informations sur la configuration du client et que son nom correspond au nom JNDI de la configuration du client. Si les valeurs sont correctes, peut s'agir d'une erreur liée au chargeur de classe.

Erreur : java.lang.ClassCastException

Erreur : java.lang.ClassCastException : Impossible de charger la classe : org.omg.stub.WebSphereSamples.HelloEJB._HelloHome_Stub at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(portableRemoteObject.java:269)

Explication Causes possibles Action recommandée
Cette exception se produit lorsque le programme d'application tente de se borner à la classe home de l'EJB et que le chargeur de classe ne peuvent pas localiser les liaisons côté client de l'EJB.
  • Les fichiers *_Stub.class et _Tie.class ne figurent pas dans le fichier .jar de l'EJB.
  • Le chargeur de classe n'a pas trouvé les classes.
Examinez le fichier JAR situé dans le fichier EAR et vérifiez que la classe contient les liaisons côté client du bean Enterprise Java Beans (EJB). Il s'agit de fichiers de classes dont les noms se terminent par _Stub et _Tie. Si les classes de liaison se trouvent bien dans le fichier JAR de l'EJB, il se peut que l'erreur soit due au chargeur de classe.

Erreur : WSCL0210EError: java.lang.NoClassDefFoundError

Erreur : WSCL0210E : Le nom du fichier EAR est introuvable. com.ibm.websphere.client.applicationclient.ClientContainerException : com.ibm.etools.archive.exception.OpenFailureException

Explication Causes possibles Action recommandée
Cette erreur se produit lorsque l'environnement d'exécution du client d'application ne peut pas lire le fichier EAR. La cause la plus probable de cette erreur est que le système ne parvient pas à trouver le fichier EAR dans le chemin d'accès spécifié dans la commande launchClient. Vérifiez que le chemin et le nom de fichier spécifiés dans la commande launchclient sont corrects.

[Windows]Si c'est le cas et que la plateforme d'exécution est Windows, utilisez une version courte du chemin et du nom de fichier (nom de fichier de 8 caractères et extension de 3 caractères).

La commande launchClient semble être suspendue et ne revient pas à la ligne de commande une fois l'exécution de l'application client terminée.

Explication Causes possibles Action recommandée
Lorsque vous exécutez le client d'application à l'aide de la commande launchClient, l'environnement d'exécution de WebSphere Application Server peut avoir besoin d'afficher la boîte de dialogue de connexion. WebSphere Application Server crée pour cela une unité d'exécution AWT (Abstract Window Toolkit). Lorsque l'application revient de sa méthode principale (main) à l'environnement d'exécution du client d'application, ce dernier tente de revenir au système d'exploitation et d'arrêter le code de la machine virtuelle Java. Toutefois, en raison de la présence d'une unité d'exécution AWT, le code de la JVM n'est pas arrêté tant que System.exit n'est pas appelée. Le code de la JVM n'est pas arrêté car il existe une unité d'exécution AWT. Le code Java attend que System.exit() soit appelé pour arrêter les unités d'exécution AWT.
  • Modifiez votre application pour qu'elle appelle System.exit(0) dans sa dernière instruction.
  • Utilisez le paramètre -CCexitVM=true lorsque vous appelez la commande launchClient. l
[Windows]

Le client d'application client d'applet ne parvient pas à lancer un navigateur HTML dans Internet Explorer

Explication Causes possibles Action recommandée
Les applications client d'applet s'exécutent seulement sous Windows. Lorsque l'application client d'applet est exécutée, les données de sortie d'application s'affichent dans une fenêtre de navigateur. Si vous utilisez Internet Explorer avec Windows XP Service Pack 2, des erreurs peuvent se produire lorsque vous tentez d'afficher les données de sortie. Le système d'exploitation Windows XP Service Pack 2 contient une fonction de sécurité qui bloque l'affichage des fenêtres en incrustation.
  • Recherchez la barre d'informations située sous la barre Adresse d'Internet Explorer où la fenêtre en incrustation a été bloquée.
  • Cliquez sur la barre d'informations pour afficher les options qui désactivent la fonction de sécurité du système d'exploitation.
  • Sélectionnez Autoriser les fenêtres intempestives. Une fenêtre vous invite à confirmer votre sélection et à autoriser la fenêtre bloquée.
  • Cliquez sur Oui.
  • L'application client de type applet s'exécute et les informations s'affichent correctement dans le navigateur.
Le service de support IBM® dispose de documents et d'outils qui peuvent vous aider à collecter plus rapidement les informations dont vous avez besoin pour résoudre votre incident. Avant d'ouvrir un rapport d'incident, consultez la page du service de support :

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rcli_troubleshoot
Nom du fichier : rcli_troubleshoot.html