1.0 Introduction
2.0 Problèmes connus
2.1
Environnement de développement Web
2.2 Débogage de WebSphere Application Server
2.3
Programme de débogage de JavaScript
2.4
Programme de débogage de procédures mémorisées SQL
2.5 Outils de test et de déploiement (outils serveur)
2.6 Débogueur JDT (Java Development Tools)
2.7 Limitations des langues autres que l'anglais
2.8 Débogueur de procédure mémorisée SQL (Linux)
2.9 Débogueur SQLJ
Les débogueurs de WebSphere Studio offrent les outils nécessaires pour déboguer les applications Web, JavaScript côté serveur, Java, SQLJ, les procédures mémorisées SQL ainsi que les langages compilés. Le présent fichier Readme décrit les problèmes et restrictions connus associés aux programmes de débogage de WebSphere Studio.
Débogage des fichiers JSP :
- Les fichiers JSP peuvent être débogués lors des tests sur un serveur WebSphere Application Server. Si les tests sont effectués sur un serveur Tomcat, le débogueur s'arrête aux points d'arrêt JSP.
- Les points d'arrêt peuvent être définis dans les fichiers JSP à l'intérieur des balises suivantes :
- Scriplets JSP de la forme : <% %>
- Expressions JSP de la forme : <%= %>
- Déclarations JSP de la forme : <%! %>
- Balises jsp:useBean, jsp:getProperty et jsp:setProperty
- Balises personnalisées
- Les points d'arrêt peuvent être définis pour les jeux de balises suivants :
- Code HTML
- Directives JSP
- Toutes les autres balises JSP standard (jsp:include, jsp:forward, etc.)
- Si vous migrez un espace de travail d'une version antérieure de WebSphere Studio vers cette version, vous devez supprimer les points d'arrêt JSP et les créer à nouveau.
- Le mode de débogage pas à pas n'aboutit pas pour les méthodes home EJB : Si vous utilisez l'adaptateur de débogage WebSphere Application Server pour lancer une session de débogage, le mode de débogage pas à pas ne s'arrête pas pour les méthodes home EJB. Utilisez des points d'arrêt si vous souhaitez déboguer ces méthodes.
- Le retour de Java à JavaScript n'est pas pris en charge : Utilisez des points d'arrêt pour pouvoir retourner à votre code JavaScript depuis Java.
- Débogage des fichiers JSP :
- Le débogage pas à pas ne fonctionne pas pour les fichiers JSP qui ne contiennent pas de code exécutable.
- Si vous utilisez l'adaptateur de débogage WebSphere Application Server pour lancer une session de débogage, vous ne pouvez ni contrôler ni afficher les expressions et les variables JSP.
- L'exécution jusqu'à la ligne n'est pas prise en charge avec les fichiers JSP.
- La définition des points d'arrêt JSP peut être lente. Prévoyez du temps supplémentaire pour l'initialisation du débogueur si le nombre de points d'arrêt JSP est élevé.
- Les points d'arrêt sur des variables statiques dans des blocs de déclaration JSP ne fonctionnent pas et peuvent provoquer d'autres dysfonctionnements des points d'arrêt.
- Les propriétés des points d'arrêt, telles que le nombre d'accès, les conditions, l'unité d'exécution sélectionnée et les règles d'interruption VM ne sont pas prises en charge pour les points d'arrêt JSP.
- Ne définissez pas de points d'arrêt Java dans l'éditeur du débogueur : Les points d'arrêt Java doivent être définis dans l'éditeur Java et non dans l'éditeur du débogueur.
- Utilisation de l'option du menu en incrustation de la vue de débogage Changer le fichier du code : Si vous avez modifié le fichier source affiché à l'aide de l'option de menu en incrustation Changer le fichier du code sur le cadre de pile, le nouveau fichier risque de ne pas s'ouvrir dans l'éditeur. Pour remédier à cela, cliquez sur un autre cadre de pile, puis sur le cadre de pile d'origine. Le nouveau fichier doit s'ouvrir dans l'éditeur.
- Console de débogage : Dans la console de débogage, les liens hypertexte vers des types ouverts ne fonctionnent pas.
- Libellés de cadre de pile après une permutation à chaud : Si, après un remplacement de code à chaud, certains des libellés de cadres de pile ont des libellés de type suivant
<type de réception inconnu>(<type de déclaration inconnu>).<nom de méthode inconnu>(<arguments inconnus>) ligne : non disponible <numéro de ligne inconnu>, vous pouvez obtenir les libellés corrects en passant à une perspective différente puis en revenant à la perspective Débogage.
- Un objet JavaScript est indisponible pour examen tant que son constructeur n'est pas achevé : Vous pouvez avancer pas à pas dans l'exécution du constructeur, mais il n'est pas possible d'examiner l'objet en cours de construction, tant qu'il n'est pas terminé (autrement dit, que vous êtes sorti du constructeur).
- Avance pas à pas et cadres de pile sous le cadre pile supérieur : Dans JavaScript, il n'est pas possible d'avancer d'un pas sans entrée, ni d'exécuter jusqu'à l'instruction de retour d'un cadre de pile différent du cadre de pile supérieur.
- JSP include : Le débogage JavaScript dans une instruction JSP include n'est pas pris en charge.
- Sortie pas à pas des fonctions récursives : Les utilisateurs déboguant des fonctions JavaScript récursives constateront que lorsqu'ils sortent pas à pas d'une fonction récursive, ils reviennent au niveau d'exécution supérieur.
- Ne développez pas les objets contenant les variables writer ou inputStream : Lorsque les utilisateurs examinent des objets JavaScript, il leur est conseillé de ne pas développer les objets contenant les variables writer ou inputStream. Si cette consigne n'est pas respectée, le débogueur ne répond pas.
- Environnement de test : Le débogage JavaScript ne fonctionne pas lors de l'utilisation de l'environnement de test WebSphere V5. Ce problème est corrigé dans le programme APAR #PQ73036.
- L'importation ou la suppression de base de données dans la vue Définition de données peut entraîner la perte des points d'arrêt définis : Ainsi, si vous déboguez une procédure mémorisée SQL avant d'importer la base de données dans un dossier de la vue Définition de données, puis importez la base de données, tous les points d'arrêt sur ligne que vous avez créés sont perdus. Une fois la base de données importée, le débogueur utilise ce dossier pour afficher la source. Si vous supprimez les informations de la base de données importée, vous perdez également les informations relatives aux points d'arrêt la prochaine fois que vous tentez de déboguer une procédure mémorisée SQL. Les points d'arrêt perdus lors de la première importation de la base de données ne sont pas restaurés.
Nous vous recommandons d'importer la base de données avant de déboguer une procédure mémorisée afin d'éviter ce problème.
- Le débogage de procédures mémorisées Java n'est pas pris en charge : L'éditeur permet d'ajouter des points d'arrêt au code source d'une procédure mémorisée Java. Toutefois, ces points d'arrêt sont ignorés car le débogage des procédures mémorisées Java n'est pas encore pris en charge.
- Noms des procédures mémorisées délimités : Le débogueur de procédures mémorisées SQL offre un support limité pour les procédures mémorisées avec des noms de procédures ou un schéma délimité. De telles procédures doivent être lancées à partir de la boîte de dialogue des configurations de lancement et non à partir du menu contextuel de la vue Définition de données.
- Support permettant d'avoir plus d'une session de débogueur de procédure mémorisée SQL active ouverte en même temps : Dans la version 5.0 de ce produit, il n'était pas possible d'avoir plus d'une session de débogueur de procédure mémorisée SQL active ouverte en même temps. Cette restriction ne s'applique plus dans la version 5.0.1 ou dans les versions ultérieures de ce produit.
- Procédures mémorisées avec des arguments FOR BIT DATA : Les procédures mémorisées qui ont des arguments pour l'attribut FOR BIT DATA ne peuvent pas être déboguées avec le débogueur de procédure mémorisée SQL WebSphere Studio.
- La configuration de lancement créée dans le produit provisoire (Early Availability) n'est peut-être pas reconnue dans le produit en cours : Si vous avez installé la version provisoire de ce produit et que vous avez créé avec celle-ci une configuration de lancement de programme de débogage de procédures mémorisées, les paramètres de cette configuration de lancement ne sont peut-être pas reconnus lorsque ce produit est utilisé avec la version en cours de ce produit. Les paramètres de configuration de lancement qui ont été sauvegardés dans la version provisoire peuvent être remplacés par les valeurs par défaut lorsque la configuration de lancement est ouverte dans la version en cours du produit.
Tenez compte des éléments ci-dessous avant de choisir d'exécuter un serveur en mode débogage :
- En mode débogage, les serveurs peuvent être plus lents à démarrer et à s'exécuter qu'en mode non-débogage.
- La compilation des pages JSP est sensiblement plus longue.
Les notes sur l'édition concernant JDT (Java development tools) ainsi que les notes sur l'édition concernant Workbench (IDE) contiennent des informations sur les problèmes et les limitations connus relatifs aux outils de développement Java. Vous trouverez des liens à ces documents dans le fichier Readme principal installé avec ce produit.
- Restriction bidirectionnelle (BiDi) : Vous ne pouvez pas utiliser l'éditeur Programme de débogage lors du débogage de fichiers JSP codés dans une page de codes autre que la page native.
- Débogueur de langage compilé :
- Sur les systèmes à simple octet (SBCS), le débogueur de langage compilé ne prend en charge ni les noms de programme ni la transmission des paramètres de programme qui contiennent des caractères dont la valeur est supérieure à 0x7F.
- L'utilisation de caractères nationaux dans les noms des programmes à déboguer et dans les arguments de débogage n'est pas prise en charge.
Lorsque vous déboguez une procédure mémorisée SQL sur une base de données locale, il est possible de recevoir le numéro d'erreur SQL1224N :
COM.ibm.db2.jdbc.DB2Exception: [IBM][Pilote CLI] SQL1224N Erreur indiquant d'un agent de base de données n'a pas pu être démarré pour traiter une demande ou a été arrêté suite à un arrêt du système de base de données ou suite à une commande force. SQLSTATE=55032
Cette erreur peut être due à un problème dans le noyau Linux (bogue #351 Bugzilla du noyau Linux). Les instructions ci-dessous constituent une solution qui utilisent la méthode de connexion TCPIP de DB2 (en tant que bouclage) et non l'interface CLI (Call Level Interface). Cette procédure permet au débogueur d'utiliser le même alias de base de données qu'auparavant :
- Si aucun port n'a été défini pour les clients DB2 éloignés, créez un port TCP/IP dans /etc/services, (par exemple, db2cdb2inst1 50000/tcp # port de service de connexion DB2). Il est possible d'utiliser un port existant pour les clients DB2 éloignés.
Pour les étapes 2 à 7, il est nécessaire que vous vous connectiez en tant que propriétaire de l'instance DB2.
- Configurez le gestionnaire de base de données afin de démarrer le gestionnaire de connexions pour le protocole de communications TCP/IP. Si vous n'êtes pas sûr que cette opération a été effectuée, émettez la commande suivante :
db2set db2commSi la sortie ne contient pas le mot clé tcpip, vous devez entrer la commande suivante afin de mettre à jour la variable de registre db2comm de manière à inclure tcpip:
db2set db2comm=<noms des protocoles existants>,tcpipLa variable de registre db2comm détermine le gestionnaire de connexions du protocole qui sera utilisé lors du démarrage du gestionnaire de bases de données. Vous pouvez définir cette variable pour plusieurs protocoles de communications en séparant les mots clé par des virgules, par exemple db2set db2comm=tcpip,appc.
Vous devez émettre à nouveau la commande db2start afin de démarrer les gestionnaires de connexions pour les protocoles indiqués par le paramètre de registre db2comm. Etant donné que nous allons redémarrer DB2 à l'étape 7 ci-dessous, il n'est pas nécessaire d'effectuer cette action maintenant.
.- Mettez à jour le paramètre de configuration du gestionnaire de bases de données SVCENAME avec le nom du service de connexion défini dans /etc/services (étape 1).
Pour vérifier le paramètre en cours de SVCENAME, entrez la commande suivante :
db2 get dbm cfg | grep -i svcenameSi vous devez mettre à jour le paramètre de SVCENAME, entrez la commande suivante :
db2 update dbm cfg using svcename <nom du service de connexion>où l'emploi des majuscules et des minuscules doit être respecté pour<nom du service de connexion>. Cet élément doit correspondre au port de service placé dans /etc/services (par exemple, db2 update dbm cfg using svcename db2cdb2inst1).
La mise à jour de la configuration du gestionnaire de bases de données ne sera effective qu'à la prochaine émission de la commande db2start. Vous effectuerez cette opération à l'étape 7 ci-dessous.
- Cataloguez le noeud de bouclage en entrant la commande suivante :
db2 catalog tcpip node <nomnoeud> remote 127.0.0.1 server <nom du service de connexion>où <nomnoeud> correspond à un alias local du noeud à cataloguer. Il s'agit d'un nom arbitraire du poste de travail, permettant d'identifier le noeud (par exemple, db2 catalog tcpip node mynode remote 127.0.0.1 server db2cdb2inst1).
Pour vérifier que la commande catalog a abouti, émettez la commande suivante :
db2 list node directoryCi-dessous se trouve une sortie exemple de cette commande (les lignes blanches ont été supprimées pour une meilleure lisibilité).
Répertoire des noeuds
Nombre d'entrées du répertoire = 1
Entrée du noeud 1 :
Nom du noeud = MYNODE
Commentaire =
Protocole = TCPIP
Nom d'hôte = 127.0.0.1
Nom du service = db2cdb2inst1- Cataloguez la base de données de la manière suivante. Reportez-vous aux commandes répertoriées ci-dessous pour générer une sortie exemple si vous souhaitez effectuer un suivi des effets de chaque commande :
- db2 catalog db <nom de la base de données> as <alias de la base de données>
- db2 uncatalog db <nom de la base de données>
- db2 catalog db <alias de la base de données en tant que <nom de la base de données> at node <nomnoeud>
par exemple,
db2 catalog db WAS as WASLOOP
db2 uncatalog db WAS
db2 catalog db WASLOOP as WAS at node MYNODERemarques :
- L'alias de la base de données peut être n'importe quel nom de votre choix mais il ne peut pas être identique au nom de la base de données.
- Si vous n'avez pas catalogué la base de données correctement, le message d'erreur numéro SQL1334N s'affiche.
- Vous devez suivre à nouveau les étapes 5a à 5c pour chaque base de données sur laquelle vous souhaitez déboguer une procédure mémorisée.
Sortie exemple des étapes 5a à 5c
Avant l'étape 5a, une base de données locale nommée WAS a déjà été créée. La commande db2 list db directory a la sortie suivante :
Répertoire de la base de données système
Nombre d'entrées du répertoire = 1
Entrée de la base de données 1 :
Alias de base de données = WAS
Nom de la base de données = WAS
Répertoire de la base de données locale = /home/ctsui
Niveau de version de la base de données = 9.00
Commentaire =
Type d'entrée de répertoire = Indirect
Numéro de noeud de catalogue = 0Après l'étape 5a, la commande db2 list db directory a la sortie suivante :
Répertoire de la base de données système
Nombre d'entrées du répertoire = 2
Entrée de la base de données 1 :
Alias de base de données = WAS
Nom de la base de données = WAS
Répertoire de la base de données locale = /home/ctsui
Niveau de version de la base de données = 9.00
Commentaire =
Type d'entrée de répertoire = Indirect
Numéro de noeud de catalogue = 0
Entrée de la base de données 2 :
Alias de la base de données 2 = WASLOOP
Nom de la base de données = WAS
Répertoire de la base de données locale = /home/ctsui
Niveau de version de la base de données = 9.00
Commentaire =
Type d'entrée de répertoire = Indirect
Numéro de noeud de catalogue = 0Après l'étape 5b, la commande db2 list db directory a la sortie suivante :
Répertoire de la base de données système
Nombre d'entrées du répertoire = 1
Entrée de la base de données 1 :
Alias de la base de données 2 = WASLOOP
Nom de la base de données = WAS
Répertoire de la base de données locale = /home/ctsui
Niveau de version de la base de données = 9.00
Commentaire =
Type d'entrée de répertoire = Indirect
Numéro de noeud de catalogue = 0Après l'étape 5c, la commande db2 list db directory a la sortie suivante :
Répertoire de la base de données système
Nombre d'entrées du répertoire = 2
Entrée de la base de données 1 :
Alias de base de données = WAS
Alias de la base de données = WASLOOP
Nom du noeud = MYNODE
Niveau de version de la base de données = 9.00
Commentaire =
Type d'entrée de répertoire = Remote
Numéro de noeud de catalogue = -1
Entrée de la base de données 2 :
Alias de la base de données 2 = WASLOOP
Nom de la base de données = WAS
Répertoire de la base de données locale = /home/ctsui
Niveau de version de la base de données = 9.00
Commentaire =
Type d'entrée de répertoire = Indirect
Numéro de noeud de catalogue = 0
Pour vérifier que la commande catalog db a abouti, émettez les deux commandes suivantes (et reportez-vous à la sortie exemple, ci-dessous) :
db2 connect to wasloop
db2 connect to wasoù db2 connect to wasloop doit imprimer les informations de connexion et db2 connect to was doit afficher le message SQL1403N.
Sortie exemple de db2 connect to wasloop :
Informations de connexion à la base de données
Répertoire de la base de données systèmeServeur de la base de données = DB2/6000 6.1.0
ID d'autorisation SQL = CTSUI
Alias de la base de données locale = WASLOOPSortie exemple de db2 connect to was :
SQL1403N Message indiquant que le nom d'utilisateur et/ou le mot de passe indiqués ne sont pas corrects. SQLSTATE=08004- Mise à jour du mécanisme d'authentification en fonction de l'authentification client. Entrez la commande :
db2 update dbm cfg using authentication client
Pour vérifier que la commande a abouti, affiche le nouveau paramètre à l'aide de la commande suivante :
db2 get dbm cfg
Sortie exemple :
....
Authentification du gestionnaire de bases de données (AUTHENTICATION) = CLIENT
....- Redémarrez DB2 pour régénérer la cache des répertoires. Par exemple,
db2stop
db2start- Pour WAS, il n'est pas nécessaire de mettre à jour le fichier admin.config. Pour une application Websphere, il n'est pas nécessaire de changer la configuration de la source de données existante.
- Si vous voulez supprimer la base de données, suivez la procédure ci-après.
- db2 attach to <nomnoeud> user <idutilisateur> using <motdepasse>
- db2 drop db <nom de la base de données>
for example, db2 attach to MYNODE user myid using mypasswd
db2 drop db WAS
Si vous effectuez une permutation à chaud lors du débogage avec la JVM J9 et qu'il existe des méthodes SQLJ dans la pile d'appels, la boîte de dialogue Méthodes obsolètes sur la pile s'affiche. Si la permutation à chaud concernait une classe SQLJ, la classe sera rechargée dans la JVM mais vous ne verrez pas le nouveau code exécuté avant un nouvel appel d'une méthode dans la classe.
Si vous effectuez une permutation à chaud d'une classe SQLJ, les points d'arrêt SQLJ peuvent ne pas fonctionner pour cette classe lors de la session de débogage en cours.
Retour au fichier Readme principal
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.