Programmes de débogage - Notes sur l'édition

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

1.0 Introduction

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.

2.0 Problèmes connus

2.1 Environnement de développement Web

Débogage des fichiers JSP :

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)

Tenez compte des éléments ci-dessous avant de choisir d'exécuter un serveur en mode débogage :

2.6 Débogueur JDT (Java Development Tools)

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.

2.7 Limitations des langues autres que l'anglais

2.8 Débogueur de procédure mémorisée SQL (Linux)

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 :

  1. 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.

  2. 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 db2comm

    Si 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>,tcpip

    La 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.

    .
  3. 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 svcename

    Si 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.

  4. 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>

    <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 directory

    Ci-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
  5. 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 :
    1. db2 catalog db <nom de la base de données> as <alias de la base de données>
    2. db2 uncatalog db <nom de la base de données>
    3. 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 MYNODE

    Remarques :

    • 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 = 0

    Aprè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 = 0

    Aprè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 = 0

    Aprè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 was

    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ème

    Serveur de la base de données = DB2/6000 6.1.0
    ID d'autorisation SQL = CTSUI
    Alias de la base de données locale = WASLOOP

    Sortie 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
  6. 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
    ....
  7. Redémarrez DB2 pour régénérer la cache des répertoires. Par exemple,
    db2stop
    db2start
  8. 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.
  9. Si vous voulez supprimer la base de données, suivez la procédure ci-après.
    1. db2 attach to <nomnoeud> user <idutilisateur> using <motdepasse>
    2. db2 drop db <nom de la base de données>
      for example, db2 attach to MYNODE user myid using mypasswd
      db2 drop db WAS

2.9 Débogueur SQLJ

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