Une ressource Web ne s'affiche pas

Utilisez cette information pour identifier et résoudre les incidents qui surviennent lors de la tentative d'affichage d'une ressource dans un navigateur.

Lorsque vous n'arrivez pas à afficher une ressource dans votre navigateur, procédez comme suit :
  1. Vérifiez le bon fonctionnement de votre serveur HTTP en accédant à l'URL http://nom_serveur à partir d'un navigateur pour voir si la page de bienvenue s'affiche. Cela vous permet de savoir si le serveur HTTP est actif, quel que soit l'état de WebSphere Application Server.
  2. Si la page de bienvenue du serveur HTTP ne s'affiche pas, c'est-à-dire si vous obtenez à la place un message du navigateur du type impossible d'afficher cette page, essayez d'identifier l'incident du serveur web.
  3. Si le serveur HTTP semble fonctionner correctement, il est possible que le serveur d'applications ne serve pas la ressource cible. Essayez d'accéder à la ressource en passant directement par le serveur d'applications au lieu du serveur HTTP.

    Si vous ne parvenez pas à accéder à la ressource directement via le serveur d'applications, vérifiez que l'URL utilisée pour accéder à la ressource est correcte.

    Si l'URL est incorrecte et a été créée sous forme de lien à partir d'un autre fichier JSP (JavaServer Pages), servlet ou fichier HTML, essayez de corriger l'URL dans la zone URL du navigateur et de la recharger afin de vérifier si l'incident est dû au format de l'URL. Rectifiez l'URL dans le fichier JSP, le servlet ou le fichier HTML indiqué à "from".

    Si l'URL semble correcte, mais que vous ne parvenez pas à accéder à la ressource directement via le serveur d'applications, vérifiez comme suit l'intégrité du serveur d'application d'hébergement et du module Web :
    1. Affichez le module Web et le serveur d'applications d'hébergement dans la console d'administration pour vérifier s'ils sont actifs.
    2. Copiez un simple fichier HTML ou JSP, tel que SimpleJsp.jsp qui se trouve dans la structure des répertoires WebSphere Application Server, dans la racine des documents de votre module Web, et essayez d'y accéder. Si vous y parvenez, cela signifie que l'incident est lié à la ressource.

      [AIX Solaris HP-UX Linux Windows][IBM i]Affichez le journal JVM de votre serveur d'applications afin de déterminer pourquoi vous ne pouvez ni trouver ni servir votre ressource.

      [z/OS]Affichez les journaux de votre serveur d'applications pour déterminer pourquoi vous ne pouvez ni trouver ni servir votre ressource.

  4. Si vous parvenez à accéder directement à la ressource via le serveur d'applications, et non un serveur HTTP, l'incident se situe au niveau du plug-in HTTP, le composant qui assure la communication entre le serveur HTTP et WebSphere Application Server.
  5. Si le fichier JSP et la sortie du servlet sont servis, mais que les ressources statiques telles que des fichiers d'image .html ne le sont pas, reportez-vous à la procédure d'activation du service de fichiers.
  6. Si certains ressources s'affichent correctement, mais que vous ne pouvez pas afficher un servlet par son nom de classe, procédez comme suit :
    • Vérifiez que le servlet se trouve dans un répertoire identifié dans le chemin d'accès aux classes du module Web, par exemple le répertoire /nom_module_Web.war/WEB-INF/classes.
    • Vérifiez que vous avez indiqué dans l'URL le nom de classe complet du servlet, y compris son nom de module.
    • Vérifiez dans l'URL que le nom de classe est précédé de "/servlet". Par exemple, si le contexte d'un module Web est "monapp" et le servlet com.macom.welcomeServlet, l'URL doit se présenter ainsi :
      http://nomhôte/myapp/servlet/com.mycom.welcomeServlet
    • Vérifiez que le service des servlets par nom de classe est activé pour le module web d'hébergement en ouvrant le module web source dans un outil d'assemblage et en consultant le paramètre Servlets traités par noms de classe de la page des propriétés des extensions IBM®. Au besoin, activez cet indicateur et redéployez le module Web.
    • L'URL des servlets ou autres ressources traités par des URL mappées est http://nomhôte/contexte racine module Web/mappedURL.

[AIX Solaris HP-UX Linux Windows][IBM i] Si aucune de ces opérations ne résout l'incident, vérifiez dans le support disponible en ligne (conseils et astuces, notes techniques et correctifs) s'il a été identifié et documenté. Si vous n'y trouvez aucune information utile, consultez l'aide IBM sur l'identification et résolution des problèmes.

Diagnostic des problèmes de serveur Web

Si vous n'arrivez pas à afficher la page de bienvenue de votre serveur HTTP, vérifiez si ce dernier fonctionne correctement.

[Windows]Ouvrez la sous-fenêtre Services du service correspondant à votre serveur HTTP, et vérifiez que l'état indiqué est Démarré. Dans le cas contraire, démarrez-le. Si le service ne démarre pas, essayez de la démarrer manuellement à partir de la ligne de commande. La commande pour le serveur HTTP IBM est rép_install_IHS\apache .

[AIX][HP-UX][Linux][Solaris]Exécutez la commande ps -ef | grep httpd. Plusieurs processus doivent s'exécuter sous le nom "httpd". Dans le cas contraire, démarrez votre serveur HTTP manuellement. La commande pour le serveur HTTP IBM est rép_install_IHS/bin/apachectl start.

Si le serveur HTTP ne démarre pas, procédez comme suit :
  • Recherchez des indices dans le journal des erreurs du serveur HTTP.
  • Essayez de restaurer la configuration du serveur HTTP antérieure à l'installation de WebSphere Application Server et redémarrez-le. Si vous utilisez un serveur HTTP IBM, procédez comme suit :
    • Renommez le fichier rép_installation_IHS\httpd.conf.
    • Copiez le fichier httpd.conf.default dans le répertoire httpd.conf.
    • Si Apache s'exécute, arrêtez puis redémarrez-le.
  • Pour le serveur Web Sun ONE (iPlanet), restaurez le fichier de configuration obj.conf pour Sun ONE version 4.1 et les fichiers obj.conf et magnus.conf pour Sun ONE version 6.0 et supérieure.
  • Dans le cas de Microsoft Internet Information Server (IIS), supprimez le plug-in de WebSphere Application Server via l'interface graphique de l'administration d'IIS.

Si la restauration du fichier de configuration par défaut du serveur HTTP réussit, passez ensuite manuellement en revue le fichier de configuration contenant les mises à jour WebSphere Application Server pour contrôler les noms de répertoire et de fichier WebSphere Application Server. Si vous n'arrivez pas à rectifier manuellement la configuration, vous pouvez désinstaller puis réinstaller WebSphere Application Server afin de créer un fichier de configuration HTTP propre.

Si la restauration du fichier de configuration par défaut ne résout pas l'incident, contactez le support d'assistance technique en charge du serveur Web que vous utilisez. Si vous utilisez IBM HTTP Server avec WebSphere Application Server, consultez le support en ligne disponible (trucs et astuces, notes techniques, correctifs). Si vous n'y trouvez aucune information utile, consultez l'aide IBM sur l'identification et résolution des problèmes.

Accès à une ressource Web via le serveur d'applications en contournant le serveur HTTP

Vous pouvez ignorer le serveur HTTP et accéder à une ressource Web via le serveur d'applications. Il n'est pas recommandé de servir un site Web de production de cette manière, mais c'est un bon outil de diagnostic lorsqu'il n'est pas évident de savoir si l'incident vient du serveur HTTP, de WebSphere Application Server ou de l'extension HTTP.

Pour accéder à une ressource Web via le serveur d'applications, procédez comme suit :
  1. Déterminez le port du service HTTP sur le serveur d'applications cible.
    1. Dans la console d'administration, cliquez sur Serveurs > Types de serveur > Serveus d'applications WebSphere > serveur_applications > Conteneur Web.
    2. Sous Propriétés supplémentaires du conteneur Web, sélectionnez Transports HTTP. Les ports des hôtes virtuels pris en charge par le serveur d'applications s'affichent.
    3. [AIX Solaris HP-UX Linux Windows][IBM i]Plusieurs ports peuvent s'afficher. Sur le serveur d'applications par défaut, (server1), par exemple, 9060 est le port réservé aux demandes d'administration et les ports 9443 et 9043 sont utilisés pour les demandes SSL chiffrées. Pour tester l'exemple de servlet "snoop", par exemple, utilisez le port d'application par défaut, 9080, à moins qu'il n'ait été modifié.
  2. Utilisez le numéro de port du transport HTTP du serveur d'applications pour accéder à la ressource à partir d'un navigateur. Par exemple, si le port est 9080, l'URL est http://nomhôte:9080/myAppContext/myJSP.jsp.
  3. Si vous n'arrivez toujours pas à accéder à la ressource, assurez-vous comme suit que le port de transport du serveur HTTP figure dans la liste "Alias d'hôte" :
    1. Cliquez sur Serveurs > Types de serveur > Serveurs d'applications WebSphere > serveur_applications > Conteneur Web > Transports HTTPpour vérifier quels sont les ports par défaut de l'hôte virtuel et du transport HTTP qu'utilise ce serveur d'applications.
    2. Pour vérifier si le port de transport HTTP existe, sélectionnez Environnement > Hôtes virtuels > hôte_par_défaut > Alias d'hôte. Au besoin, ajoutez une entrée. Par exemple, si le port HTTP de votre serveur d'applications est 9080, ajoutez l'alias d'hôte *:9082.

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_pagedisplayprob
Nom du fichier : rtrb_pagedisplayprob.html