Debugger - Note sul rilascio

1.0 Introduzione
2.0 Problemi noti
   2.1 Ambiente di sviluppo Web
   2.2 Debug su WebSphere Application Server
   2.3 Debugger JavaScript
   2.4 Debugger delle procedure memorizzate SQL
   2.5 Strumenti per il test e la distribuzione (strumenti server)
   2.6 Debugger JTD (Java Development Tools)
   2.7 Limitazioni relative alle versioni tradotte
   2.8 Debugger procedure memorizzate SQL (Linux)
   2.9 Debugger SQLJ

1.0 Introduzione

I debugger in WebSphere Studio forniscono gli strumenti necessari per eseguire il debug di applicazioni Web JavaScript del server, Java, SQLJ, Procedure memorizzate SQL e linguaggi compilati. Questo file readme descrive i problemi noti e le limitazioni associate ai debugger di WebSphere Studio.

2.0 Problemi noti

2.1 Ambiente di sviluppo Web

Debug JSP:

2.2 Debug di WebSphere Application Server

2.3 Debugger JavaScript

2.4 Debugger delle procedure memorizzate SQL

2.5 Strumenti per il test e la distribuzione (strumenti server)

Quando si esegue un server in modalità debug, ricordarsi che:

2.6 Debugger JDT (Java Development Tools)

Le informazioni relative ai problemi noti e alle limitazioni degli strumenti di sviluppo Java, sono disponibili nelle note sul rilascio di JDT (Java Development Tools) e del Workbench (IDE). I collegamenti a tali argomenti sono disponibili nel readme installato con il prodotto.

2.7 Limiti relativi alle versioni tradotte

2.8 Debugger procedure memorizzate SQL (Linux)

Se si sottopone a debug una procedura memorizzata SQL su un database locale, è possibile ricevere l'errore numero SQL1224N:

COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N Un agente di database non è stato avviato per eseguire una richiesta oppure è stato terminato in seguito alla chiusura del sistema database o a un comando forzato. SQLSTATE=55032

Questo errore è dovuto a un problema nel kernel di Linux (Linux kernel Bugzilla bug #351). Le seguenti istruzioni consentono di risolvere il problema utilizzando il metodo di connessione TCPIP di DB2 invece di CLI (Call Level Interface). Questa procedura consentirà al debugger di utilizzare lo stesso alias di database:

  1. Se non è stata impostata alcuna porta per i client DB2 remoti, creare una porta TCP/IP in /etc/services, (ad esempio, db2cdb2inst1 50000/tcp # DB2 connection service port). È possibile utilizzare una porta esistente per i client DB2 remoti.

    Per svolgere le operazioni riportate ai punti dal 2 al 7, è necessario collegarsi come proprietario dell'istanza DB2.

  2. Configurare il database manager in modo che avvii la connessione per il protocollo di comunicazione TCP/IP. Per verificare che questa impostazione sia già stata applicata, eseguire il seguente comando:
    db2set db2comm

    Se l'output non contiene la parola chiave tcpip, è necessario eseguire il seguente comando per aggiornare la variabile di registro db2comm in modo che includa tcpip:

    db2set db2comm=<existing protocol names>,tcpip

    La variabile di registro db2comm determina la connessione del protocollo che verrà abilitata all'avvio di database manager. È possibile impostare questa variabile per più protocolli di comunicazione, separando le parole chiave con virgole, ad esempio db2set db2comm=tcpip,appc.

    È necessario rieseguire il comando db2start per avviare le connessioni per i protocolli specificati dal parametro di registro db2comm. Poiché al punto 7 viene suggerito di riavviare DB2, non è necessario riavviarlo adesso.

    .
  3. Aggiornare il parametro di configurazione di database manager SVCENAME con il nome del servizio di connessione definito in /etc/services (punto 1).

    Per verificare le impostazioni correnti di SVCENAME, immettere il seguente comando:

    db2 get dbm cfg | grep -i svcename

    Per aggiornare le impostazioni di SVCENAME, immettere il seguente comando:

    db2 update dbm cfg using svcename <nome servizio connessione>

    dove <nome servizio connessione> rileva la differenza tra maiuscolo e minuscolo e deve corrispondere al nome della porta del servizio specificata in /etc/services (ad esempio, db2 update dbm cfg using svcename db2cdb2inst1).

    L'aggiornamento della configurazione di database manager non avrà effetto fino a quando non viene eseguito nuovamente il comando db2start. Questa operazione viene eseguita al punto 7.

  4. Catalogare il nodo di loopback immettendo il seguente comando:
    db2 catalog tcpip node <nomenodo> remote 127.0.0.1 server <nome servizio di connessione>

    dove <nomenodo> è un alias locale per il nodo da catalogare. Questo sarà un nome arbitrario sulla stazione di lavoro, utilizzato per identificare il nodo (ad esempio, db2 catalog tcpip node mynode remote 127.0.0.1 server db2cdb2inst1).

    Per verificare che il comando di catalogo ha funzionato correttamente, eseguire il seguente comando:

    db2 list node directory

    Un output di esempio di questo comando potrebbe essere (le righe vuote sono state rimosse per una migliore leggibilità):

    Directory nodo
    Numero di voci nella directory = 1
    Voci nodo 1:
    Nome nodo = MYNODE
    Commento =
    Protocollo = TCPIP
    Nome host = 127.0.0.1
    Nome servizio = db2cdb2inst1
  5. Catalogare il database come segue. Fare riferimento ai comandi indicati di seguito per generare un output di esempio se si desidera tenere traccia degli effetti di ciascun comando:
    1. db2 catalog db <nome database> as <alias database>
    2. db2 uncatalog db <nome database>
    3. db2 catalog db <database alias as <nome database> at node <nome nodo>
    ad esempio,
    db2 catalog db WAS as WASLOOP
    db2 uncatalog db WAS
    db2 catalog db WASLOOP as WAS at node MYNODE

    Note:

    • L'alias del database può essere qualsiasi nome ma non può essere uguale al nome del database.
    • Se il database non viene catalogato correttamente, verrà ricevuto l'errore numero SQL1334N.
    • È necessario ripetere i punti da 5a a 5c per ciascun database in cui si desidera eseguire il debug di una procedura memorizzata.

    Output di esempio per i punti da 5a a 5c

    Prima di eseguire il punto 5a, è necessario che il database locale WAS sia già stato creato. Il comando db2 list db directory avrà il seguente output:

    Directory del database di sistema
    Numero di voci nella directory = 1

    Voci database 1:

    Alias database = WAS
    Nome database = WAS
    Directory database locale = /home/ctsui
    Livello di rilascio del database = 9.00
    Commento =
    Tipo di immissione nella directory = Indirect
    Numero nodo del catalogo = 0

    Dopo il punto 5a, il comando db2 list db directory avrà il seguente output:

    Directory del database di sistema
    Numero di voci nella directory = 2

    Voci database 1:

    Alias database = WAS
    Nome database = WAS
    Directory database locale = /home/ctsui
    Livello di rilascio del database = 9.00
    Commento =
    Tipo di immissione nella directory = Indirect
    Numero nodo del catalogo = 0

    Voci database 2:

    Alias database = WASLOOP
    Nome database = WAS
    Directory database locale = /home/ctsui
    Livello di rilascio del database = 9.00
    Commento =
    Tipo di immissione nella directory = Indirect
    Numero nodo del catalogo = 0

    Dopo il punto 5b, il comando db2 list db directory avrà il seguente output:

    Directory del database di sistema
    Numero di voci nella directory = 1

    Voci database 1:

    Alias database = WASLOOP
    Nome database = WAS
    Directory database locale = /home/ctsui
    Livello di rilascio del database = 9.00
    Commento =
    Tipo di immissione nella directory = Indirect
    Numero nodo del catalogo = 0

    Dopo il punto 5c, il comando db2 list db directory avrà il seguente output:

    Directory del database di sistema
    Numero di voci nella directory = 2

    Voci database 1:

    Alias database = WAS
    Nome database = WASLOOP
    Nome nodo = MYNODE
    Livello di rilascio del database = 9.00
    Commento =
    Tipo di immissione nella directory = Remote
    Numero nodo del catalogo = -1

    Voci database 2:

    Alias database = WASLOOP
    Nome database = WAS
    Directory database locale = /home/ctsui
    Livello di rilascio del database = 9.00
    Commento =
    Tipo di immissione nella directory = Indirect
    Numero nodo del catalogo = 0

    Per verificare che il comando catalog db ha funzionato correttamente, eseguire i due comandi seguenti (e fare riferimento all'output di esempio riportato di seguito):

    db2 connect to wasloop
    db2 connect to was

    dove db2 connect to wasloop visualizza le informazioni di connessione e db2 connect to was visualizza SQL1403N.

    Esempio di output di db2 connect to wasloop:

    Informazioni di connessione al database
    Directory del database di sistema

    Server database = DB2/6000 6.1.0
    ID di autorizzazione SQL = CTSUI
    Alias database locale = WASLOOP

    Esempio di output di db2 connect to was:

    SQL1403N Il nome utente e/o la password forniti non sono corretti. SQLSTATE=08004
  6. Aggiornare il meccanismo di autenticazione su Autenticazione client. Eseguire il comando:
    db2 update dbm cfg using authentication client

    Per verificare che il comando ha funzionato correttamente, visualizzare le nuove impostazioni con il seguente comando:

    db2 get dbm cfg

    Output di esempio:

    ....
    Autenticazione database manager         (AUTHENTICATION) = CLIENT
    ....
  7. Riavviare DB2 per aggiornare la cache delle directory. Ad esempio,
    db2stop
    db2start
  8. Per WAS, non c'è alcun bisogno di aggiornare il file admin.config. Per l'applicazione Websphere, non c'è alcun bisogno di modificare la configurazione dell'origine dati esistente.
  9. Se si desidera cancellare il database, procedere come segue:
    1. db2 attach to <nome nodo> user <id utente> using <password>
    2. db2 drop db <nome database>
      ad esempio, db2 attach to MYNODE user myid using mypasswd
      db2 drop db WAS

2.9 Debugger SQLJ

Durante l'esecuzione di swap attivi durante il debug con J9 JVM, se vi sono metodi SQLJ sullo stack di chiamate, verrà visualizzata la finestra Metodi obsoleti nello stack. Se lo swap attivo era riferito a una classe SQLJ, la classe verrà ricaricata nella JVM, ma il nuovo codice in esecuzione non verrà visualizzato fino al prossimo richiamo di un metodo nella classe.

Se si esegue lo swap attivo di una classe SQLJ, i punti di interruzione SQLJ non funzioneranno per la classe durante la sessione di debug corrente.

Visualizza il file Readme principale