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. |
|
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.HelloHomevé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. |
- Ouvrez votre fichier EAR avec un outil d'assemblage, et sélectionnez le client d'application.
- Ajoutez les noms des autres fichiers JAR contenus dans le fichier EAR à 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.
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.
Le caractère de séparation est le signe deux-points.
Le caractère de séparation est le signe deux-points.
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. |
|
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. |
|
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é. |
|
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]](../images/windows.gif)
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. |
|
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. |
|
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. |
|
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.
|
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. |
|
![[Windows]](../images/windows.gif)
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. |
|