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
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.
Debug JSP:
- I file JSP possono essere sottoposti a debug durante la verifica su WebSphere Application Server. Se si esegue la verifica su un server Tomcat, il debugger non si fermerà ai punti di interruzione JSP.
- I punti di interruzione possono essere impostati nei file all'interno dei seguenti tag:
- Scriptlet del modulo: <% %>
- Espressioni JSP del modulo: <%= %>
- Dichiarazioni JSP con formato: <%! %>
- Tag jsp:useBean, jsp:getProperty e jsp:setProperty
- Tag personalizzati
- I punti di interruzione non possono essere impostati per i seguenti insiemi di tag:
- Codice HTML
- Direttive JSP
- Tutti gli altri tag JSP standard (jsp:include, jsp:forward e così via)
- Se si esegue la migrazione di uno spazio di lavoro da una vecchia versione di WebSphere Studio alla versione corrente, è necessario eliminare i punti di interruzione JSP e ricrearli.
- La modalità di debug per passi avrà esito negativo con alcuni metodi locali EJB: se si utilizza l'adattatore di debug di WebSphere Application Server per avviare una sessione di debug, la modalità di debug per passi non si arresterà per alcuni metodi locali EJB. Per eseguire il debug di questi metodi è necessario utilizzare i punti di interruzione.
- L'operazione di inversione da Java a JavaScript non è supportata: utilizzare i punti di interruzione se si desidera ritornare al codice JavaScript da Java.
- Debug dei JSP:
- Il debug per passi non verrà eseguito per i JSP che non contengono codice eseguibile.
- Se si utilizza l'adattatore di debug di WebSphere Application Server per avviare una sessione di debug, non sarà possibile esaminare o visualizzare variabili o espressioni JSP.
- Nei JSP non è supportata la funzione di esecuzione fino alla riga.
- L'impostazione dei punti di interruzione JSP potrebbe essere lenta. Più numerosi sono i punti di interruzione JSP, maggiore dovrà essere il tempo previsto per consentire al debugger di eseguire l'inizializzazione.
- I punti di interruzione sulle variabili statiche nei blocchi di dichiarazioni JSP non funzionano e potrebbero causare altri problemi ai punti di interruzione.
- Alcune proprietà dei punti di interruzione, come ad esempio numero passaggi, condizione, thread selezionato o i criteri di sospensione della VM, non sono supportate per i punti di interruzione JSP.
- Non impostare punti di interruzione Java nell'editor Debugger: i punti di interruzione Java devono essere impostati nell'editor Java e non nell'editor Debugger.
- Utilizzo della voce del menu di scelta rapida della vista Cambia file di origine: se si modifica il file di origine visualizzato utilizzando la voce del menu di scelta rapida Cambia file di origine nel frame dello stack, il nuovo file potrebbe non essere visualizzato nell'editor. Per risolvere questo problema, fare clic su un altro frame dello stack e quindi fare clic di nuovo sul frame dello stack originale. In questo modo il nuovo file dovrebbe essere aperto nell'editor.
- Console di debug: nella console di debug, i collegamenti ipertestuali ai tipi aperti non funzionano.
- Etichette del frame dello stack dopo una sostituzione in modalità attiva: se, dopo la sostituzione del codice attivo, alcuni frame dello stack hanno etichette come
<unknown receiving type>(<unknown declaring type>). <unknown method name>(<unknown arguments>) line: not available <unknown line number>è possibile ottenere le etichette corrette passando ad un'altra prospettiva e tornando alla prospettiva Debug.
- Non è possibile esaminare un oggetto JavaScript fino al completamento del relativo costruttore: è possibile passare attraverso l'esecuzione del costruttore, ma non è possibile esaminare l'oggetto in costruzione fino al completamento della costruzione (chiusura del costruttore).
- Avanzamento per passi e frame dello stack sottostanti al frame dello stack superiore: in JavaScript le operazioni Passa su o Passa a precedente relative ai frame dello stack diversi da quello superiore, non sono consentite.
- JSP include: non è supportato il debug JavaScript in JSP include.
- Uscita da funzioni ricorsive: quando si esegue il debug di funzioni JavaScript ricorsive, in caso di uscita, si ritorna al primo livello di esecuzione.
- Non espandere oggetti contenenti variabili writer o inputStream: durante l'esame di oggetti JavaScript, gli utenti vengono avvisati di non espandere oggetti contenenti le variabili writer o inputStream. Questa operazione infatti interromperebbe le comunicazioni con il debugger.
- Ambiente di test: il debug di JavaScript non funziona quando si utilizza WebSphere V5 Test Environment. Questo problema è stato risolto con la correzione APAR #PQ73036.
- L'importazione e l'eliminazione del database nella vista Definizione dati può provocare la perdita dei punti di interruzione impostati: se si esegue il debug di una procedura memorizzata SQL prima di importare il database in una cartella della vista Definizione dati e poi si importa il database, tutti i punti di interruzione di riga creati andranno persi. Una volta importato il database, il debugger utilizzerà quella cartella per visualizzare l'origine. Se si eliminano le informazioni sul database importato, si perderanno anche quelle sui punti di interruzione la volta successiva che si tenta di eseguire il debug di una procedura memorizzata SQL. In tal modo, non si ripristineranno i punti di interruzione persi quando il database viene importato la prima volta.
Per evitare questo problema, si consiglia di importare il database prima di eseguire il debug di una procedura memorizzata.
- Il debug delle procedure memorizzate Java non è supportato: l'editor consente di aggiungere punti di interruzione al codice di origine di una procedura memorizzata Java. Tuttavia, questi punti di interruzione vengono ignorati in quanto il debug delle procedure Java non è ancora supportato.
- Nomi delle procedure memorizzate limitati: il debugger delle procedure memorizzate SQL fornisce supporto limitato per le procedure con supporto e nomi determinati. Tali procedure dovranno essere avviate dalla finestra Avvia configurazione e non dal menu di scelta rapida nella vista Definizione dati.
- Supporto per più sessioni per il debug di procedure memorizzate SQL attive allo stesso tempo: nella versione 5.0 di questo prodotto, non era possibile avere più di una sessione per il debug delle procedure memorizzate SQL aperta allo stesso tempo. Questa limitazione non riguarda la versione 5.0.1 o le versioni successive di questo prodotto.
- Procedure memorizzate per argomenti FOR BIT DATA: le procedure memorizzate che contengono argomenti con l'attributo FOR BIT DATA non possono essere sottoposte a debug con il debug delle procedure memorizzate SQL di WebSphere Studio.
- La configurazione di avvio creata con la versione EA (Early Availability) del prodotto potrebbe non essere riconosciuta nel prodotto corrente: se è stata installata la versione EA (Early Availability) di questo prodotto in cui è stata creata la configurazione di avvio del debugger delle procedure memorizzate, è possibile che le impostazioni della configurazione non vengano riconosciute dalla versione corrente di questo prodotto. Le impostazioni della configurazione di attivazione salvate nella versione EA (Early Availability), potrebbero essere annullate ripristinando i valori predefiniti se questa configurazione viene aperta nella versione corrente del prodotto.
Quando si esegue un server in modalità debug, ricordarsi che:
- L'avvio e l'esecuzione del server può essere più lenta rispetto a un'altra modalità.
- La compilazione delle pagine JSP può durare più a lungo.
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.
- Limitazioni BiDi (Bidirectional): non è possibile utilizzare l'editor Debugger quando si esegue il debug dei JSP che sono stati codificati con una codepage diversa da quella nativa.
- Debugger linguaggio compilato:
- In sistemi a byte singolo (SBCS), il debugger per il linguaggio compilato non supporta i nomi dei programmi o il passaggio di parametri del programma contenenti caratteri superiori a 0x7F.
- L'uso di caratteri nazionali nei nomi e negli argomenti di debug non è supportato.
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:
- 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.
- 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 db2commSe 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>,tcpipLa 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.
.- 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 svcenamePer 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.
- 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 directoryUn 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- 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:
- db2 catalog db <nome database> as <alias database>
- db2 uncatalog db <nome database>
- 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 MYNODENote:
- 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 = 0Dopo 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 = 0Dopo 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 = 0Dopo 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 wasdove 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 sistemaServer database = DB2/6000 6.1.0
ID di autorizzazione SQL = CTSUI
Alias database locale = WASLOOPEsempio di output di db2 connect to was:
SQL1403N Il nome utente e/o la password forniti non sono corretti. SQLSTATE=08004- 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
....- Riavviare DB2 per aggiornare la cache delle directory. Ad esempio,
db2stop
db2start- 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.
- Se si desidera cancellare il database, procedere come segue:
- db2 attach to <nome nodo> user <id utente> using <password>
- db2 drop db <nome database>
ad esempio, db2 attach to MYNODE user myid using mypasswd
db2 drop db WAS
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
(C) Copyright IBM Corporation 2000, 2003. Tutti i diritti riservati.