Incidents liés à l'accès aux applications

Pour résoudre les incidents liés à l'accès d'un servlet, d'un fichier JavaServer Pages, d'une application autonome ou d'un autre client à un bean enterprise, un pool de connexions ou tout autre objet nommé hébergé par WebSphere Application Server, commencez par vérifier que le serveur cible est accessible à partir du client.

Effectuez les étapes suivantes :
  • A partir d'une invite du serveur du client, entrez ping nom_serveur et vérifiez la connectivité.
  • Utilisez la console d'administration pour vérifier que le serveur d'applications de la ressources cible et, au besoin, le module EJB ou web, ont été démarrés.

Ne poursuivez qu'en l'absence d'incident de connectivité et si la ressource cible semble s'exécuter.

Si vous ne trouvez pas d'incident similaire au vôtre, ou que les informations fournies ne permettent pas de le résoudre, prenez contact avec le support technique IBM®.

Exception NameNotFoundException d'une opération de recherche JNDI

Il existe trois causes pour qu'une exception NameNotFoundException se produise :

Nom de recherche incorrect
Si vous êtes confronté à une exception NameNotFoundException lors d'une tentative d'accès à un bean enterprise, une source de données, une ressource de messagerie ou toute autre ressource, procédez comme suit :
  1. Déterminez la cause de l'exception NameNotFoundException.

    Parcourez les propriétés de l'objet cible dans la console d'administration et vérifiez que le nom JNDI (Java™ indiqué correspond au nom JNDI qu'utilise le client.

    Si vous recherchez un objet résidant sur un autre serveur que celui d'où provient le contexte initial, vous devez utiliser le nom complet.
    • Lorsque l'accès s'effectue à partir d'un autre objet serveur, tel un servlet accédant à un bean enterprise alors que vous utilisez le contexte par défaut, sans indiquer le nom complet JNDI, vous risquez d'obtenir une exception NameNotFoundException si l'objet se trouve sur un autre serveur.
    • Lorsque l'accès s'effectue à partir d'un client autonome, il est possible que l'objet auquel vous tentez d'accéder se trouve sur un autre serveur que celui d'où provient le contexte initial.
  2. Utilisez le nom JNDI complet pour résoudre l'incident.
    Si l'objet se trouve dans un serveur unique, le nom JNDI complet est le suivant :
    cellule/noeuds/nomNoeud/serveurs/nomServeur/Nomjndi
    Restriction : Les objets ne sont pas pris en charge dans cette version.
    Si l'objet se trouve dans un cluster de serveurs, le nom JNDI complet est le suivant :
    cellule/clusters/nomCluster/nomJndi
L'objet recherché n'est pas lié
Pour corriger une exception NameNotFoundException dans laquelle l'objet recherché n'est pas lié :
  1. Si l'objet recherché se trouve dans un objet application tel qu'un bean enterprise, assurez-vous que l'application est active.
  2. Exécutez l'outil dumpNameSpace pour afficher le contenu de l'espace de nom et vérifier que l'objet recherché est lié à l'espace de nom muni du nom prévu.
Deux serveurs ayant le même nom et actifs sur le même hôte sont utilisés pour assurer l'interopérabilité
Si une application s'exécutant sur un serveur du noeud1 utilise une référence d'objet distant à un objet se trouvant sur un serveur portant le même nom du noeud2 et que les deux noeuds sont installés sur le même hôte, plusieurs incidents différents peuvent se produire :
  • Les recherches JNDI échouent avec un NameNotFoundException.
  • Les références d'objet obtenues via des moyens autre que les recherches JNDI échouent, la plupart du temps avec une exception org.omg.CORBA.OBJECT_NOT_EXIST.
  • Une référence d'objet distant ne se résout pas correctement en un objet dans le processus local car l'objet existe également dans le processus local. En d'autres termes, une référence à un objet distant sur le processus serveur dans le noeud 2 est résolu de façon incorrecte vers le même type d'objet dans le processus local, ce qui correspond au processus serveur dans le noeud 1.

Les références d'objets entre des serveurs de noeuds différents et situées sur des hôtes différents n'entraînent pas d'exception même si les noms de serveur ne sont pas uniques.

Pour corriger les incidents, définissez une propriété personnalisée JVM (Java Virtual Machine) pour la fonction ORB (Object Request Broker), com.ibm.websphere.orb.uniqueServerName, sur true pour l'un ou l'autre des serveurs, ou les deux :
  1. Dans la console d'administration, cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere > nom_serveur > Gestion des processus et Java > Définition des processus > Machine virtuelle Java > Propriétés personnalisées > Nouveau.
  2. Sur la page de paramètres Propriétés personnalisées, définissez la propriété personnalisée :
    1. Pour Nom, définissez com.ibm.websphere.orb.uniqueServerName.
    2. Pour Valeur, définissez true.
  3. Cliquez sur OK.
  4. Cliquez sur Sauvegarder dans la barre des tâches de la console.
  5. Redémarrez le serveur d'applications.

Pour éviter de tels incidents avec l'agent de noeud, vous pouvez définir la fonction ORB de la propriété personnalisée de la machine virtuelle Java de l'agent de noeud ORB, com.ibm.websphere.orb.uniqueServerName, avec la valeur true.

Exception CannotInstantiateObjectException d'une opération de recherche JNDI

Si vous êtes confronté à cette exception lors d'une tentative d'accès à un bean enterprise, une source de données, une ressource de messagerie ou toute autre ressource, les causes possibles sont les suivantes :
  • Vous recherchez un objet Java sérialisé alors que l'environnement d'exécution ne contient pas les classes requises pour désérialiser l'objet.
  • Vous recherchez un objet de référence mais la fabrique associée utilisée pour traiter l'objet dans le cadre du processus de recherche est défaillante.
Pour détermine la cause précise de l'incident, procédez comme suit :
  • Consultez les exceptions précédant immédiatement l'exception CannotInstantiateObjectException. S'il s'agit d'une exception java.lang.NoClassDefFoundError ou java.lang.ClassNotFoundException, vérifiez que la classe référencée dans le message d'erreur peut être localisée par le chargeur de classe..

    [AIX][Linux][HP-UX][Solaris][Windows][IBM i]Affichez les journaux de la JVM.

    [z/OS]Affichez les fichiers journaux du serveur qui héberge la ressource cible.

  • Imprimez la trace de pile de la cause principale et recherchez la classe de la fabrique. Elle sera appelée par javax.naming.NamingManager.getObjectInstance(). La raison de l'échec dépend de la mise en oeuvre de la fabrique et peut nécessiter de contacter le développeur de la classe de la fabrique.

Message NMSV0610I dans le fichier journal du serveur indiquant qu'une exception Naming s'est produite

Ce message purement informatif s'affiche lorsque l'exception est liée à un incident réel. La plupart du temps, ce n'est pas le cas. Sinon, le fichier journal doit contenir des entrées adjacentes pour fournir le contexte.

  • En l'absence d'incident, ignorez ce message. Ignorez également le message si l'incident auquel vous êtes confronté ne semble pas lié à l'exception signalé et si le journal de contient aucun message d'erreur adjacent.
  • En cas d'incident, recherchez dans le journal des messages d'erreur sous-jacents.
  • Les informations du message NMSV0610Ifournissent des données de débogage très utiles pour d'autres messages d'erreur adjacents envoyés en réponse à l'exception Naming qui s'est produite.

Exception OperationNotSupportedException d'une opération JNDI Context

Deux causes possibles :
  • Une opération de mise à jour, telle qu'une édition de liens, est effectuée avec un nom commençant par "java:comp/env". Ce contexte et ses contextes sous-jacents sont en lecture seule.
  • Une opération de liaison de contexte d'un objet non CORBA est effectuée sur un espace nom distant qui n'appartient pas au produit. Seuls les objets CORBA peuvent être liés à ces espaces nom CosNaming.

Pour déterminer laquelle de ces erreurs pose problème, vérifiez l'intégralité du message de l'exception.

WSVR0046E : Echec de liaison, ejb/NomJNDI : ejb/NomJNDI. Exception d'origine : org.omg.CosNaming.NamingContextPackage.AlreadyBound

Cette erreur se produit lorsque deux applications serveur de bean enterprise ont été installées sur le même serveur ce qui provoque un conflit de nom de liaison. En fait, le nom JNDI est le même dans les descripteurs de déploiement des deux applications. L'erreur se manifeste au démarrage du serveur lorsque la seconde application utilisant ce même nom JNDI démarre.

Pour vérifier s'il s'agit bien de l'origine de l'incident, examinez les descripteurs de déploiement de toutes les applications serveur de bean enterprise qui s'exécutent sur le serveur pour voir s'ils contiennent un nom JNDI spécifié dans plusieurs applications de bean enterprise.

Pour résoudre cet incident, modifiez tous les noms JNDI en double de sorte que la liaison de chaque bean enterprise du processus serveur soit effectuée avec un nom différent.

Exception ConfigurationException d'une opération "new InitialContext" ou JNDI Context avec nom d'URL

Lorsque vous tentez d'obtenir un contexte JNDI initial, une exception de configuration peut se produire car une valeur de propriété JNDI incorrecte a été transmise au constructeur du contexte initial. Il s'agit notamment du jeu de propriétés JNDI inclus dans les propriétés système ou dans un fichier jndi.properties visible du chargeur de classe actif. En général, une propriété incorrecte découle d'une URL de fournisseur syntaxiquement erronée. Si le client JNDI et exécuté en tant que client thin de sorte que CLASSPATH intègre tous les fichiers jar individuels requis, assurez-vous que le fichier .jar contenant le fichier de propriétés com/ibm/websphere/naming/jndiprovider.properties se trouve dans CLASSPATH.

Si l'exception se produit à partir d'un appel de contexte JNDI effectué avec un nom au format d'URL, il se peut que la configuration JNDI en cours ne soit pas bien définie de sorte qu'il est impossible de déterminer le nom de classe de la fabrique requise ou que la fabrique n'est pas visible du chargeur de classe actuellement actif. Si le nom est une URL Java, le client JNDI doit s'exécuter dans un client Java EE (Java Platform, Enterprise Edition) ou un environnement serveur. C'est-à-dire que le client doit s'exécuter dans un conteneur.

Vérifiez le message d'exception pour identifier sa cause.

Si l'exception provient du constructeur du contexte initial, rectifiez les paramètres de propriété ou la valeur de CLASSPATH.

Si l'exception provient d'une méthode JNDI Context, assurez-vous que la propriété java.naming.factory.url.pkgs contient le nom de module de la fabrique requise pour le schéma d'URL du nom. Les noms d'URL au schéma Java ne sont utilisables que pour exécution dans un conteneur.

Exception ServiceUnavailableException d'une opération "new InitialContext"

Cette exception signale qu'un incident imprévu s'est produit lors d'une tentative de contacter le serveur de noms afin d'obtenir un contexte initial. Vous pouvez rechercher le ServiceUnavailableException de la cause d'un incident. Pour plus d'informations, déterminez la cause de l'incident. Certains des incidents décrits pour les exceptions CommunicationExceptions peuvent également mener à l'exception ServiceUnavailableException.

Cette exception étant déclenchée par une erreur imprévue, il n'y pas de cause probable à confirmer. Si l'exception liée à la cause de l'incident n'indique pas quelle est la cause probable, recherchez dans les causes possibles répertoriés pour les exceptions CommunicationExceptions.

Exception CommunicationException provenant d'une opération "new InitialContext"

Impossible de contacter le serveur de noms identifié par l'URL du fournisseur afin d'obtenir le contexte JNDI initial. Les causes de cet incident peuvent être multiples, notamment :
  • Le nom d'hôte ou le port indiqué dans l'URL du fournisseur est incorrect.
  • Le serveur de nom de domaine n'arrive pas à convertir le nom d'hôte en adresse IP ou l'adresse IP obtenue de correspond pas à l'adresse IP sous laquelle le serveur s'exécute actuellement.
  • Un pare-feu installé sur le client ou le serveur empêche l'utilisation du port indiqué dans l'URL du fournisseur.
Pour résoudre le problème, procédez comme suit :
  • Vérifiez que l'URL du fournisseur et les configurations de réseau du client et des machines serveur sont corrects.
  • Vérifiez que le nom d'hôte peut être converti en adresse IP à laquelle la machine client peut accéder. Pour ce faire, vous pouvez utiliser la commande ping.
  • Si vous exécutez un pare-feu, assurez-vous que l'utilisation du port indiqué dans l'URL du fournisseur sera autorisée.

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=rtrb_namingprobs
Nom du fichier : rtrb_namingprobs.html