1.0 Einführung
2.0 Bekannte Probleme
2.1 Web-Entwicklungsumgebung
2.2 Debug von WebSphere Application Server
2.3 JavaScript-Debugger
2.4 SQL - Gespeicherte Prozeduren - Debugger
2.5 Tools für Test und Implementierung (Servertools)
2.6 Java Development Tools (JDT) - Debugger
2.7 Einschränkungen bei Landessprachen
2.8 SQL - Gespeicherte Prozeduren - Debugger (Linux)
2.9 SQLJ - Debugger
Die Debugger in WebSphere Studio bieten die Tools, die zum Debug von Webanwendungen, serverseitigem JavaScript, Java, SQLJ, gespeicherten SQL-Prozeduren und Compilersprachen benötigt werden. In dieser Readme-Datei werden die bekannten Probleme und Einschränkungen hinsichtlich der WebSphere Studio-Debugger beschrieben.
JSP-Debug:
- Für JSP-Dateien kann ein Debug ausgeführt werden, wenn sie auf einem WebSphere Application Server getestet werden. Wenn Sie auf einem Tomcat-Server testen, stoppt der Debugger nicht bei JSP-Unterbrechungspunkten.
- Unterbrechungspunkte können in JSP-Dateien innerhalb der folgenden Tags gesetzt werden:
- JSP-Scriptlets mit dem Format: <% %>
- JSP-Ausdrücke mit dem Format: <%= %>
- JSP-Deklarationen mit dem Format: <%! %>
- JSP-Tags 'jsp:useBean', 'jsp:getProperty' und 'jsp:setProperty'
- Angepasste Tags
- Unterbrechungspunkte können für die folgenden Tag-Gruppen nicht gesetzt werden:
- HTML-Code
- JSP-Anweisungen
- Alle übrigen JSP-Standardtags ('jsp:include', 'jsp:forward' usw.)
- Wenn Sie einen Arbeitsbereich von einer älteren Version von WebSphere Studio zu dieser Version migrieren, ist es erforderlich, die JSP-Unterbrechungspunkte zu löschen und neu zu erstellen.
- Step-by-Step-Debugmodus für schrittweises Debug schlägt für EJB-Home-Methoden fehl: Wenn Sie den Debug-Adapter von WebSphere Application Server zum Starten einer Debugsitzung verwenden, stoppt der Step-by-Step-Debugmodus bei EJB-Home-Methoden nicht. Verwenden Sie Unterbrechungspunkte, wenn Sie diese Methoden debuggen wollen.
- Step-Return-Operation von Java zurück zu JavaScript wird nicht unterstützt: Verwenden Sie Unterbrechungspunkte, wenn Sie von Java zu Ihrem JavaScript-Code zurückkehren möchten.
- Debug von JSPs:
- Das schrittweise Debug funktioniert nicht bei JSPs, die keinen ausführbaren Code enthalten.
- Falls Sie den Debugadapter von WebSphere Application Server verwenden, um eine Debugsitzung zu starten, können JSP-Variablen und -Ausdrücke weder untersucht noch angezeigt werden.
- Die Ausführung bis zu einer bestimmten Zeile wird bei JSPs nicht unterstützt.
- Möglicherweise dauert das Setzen von JSP-Unterbrechungspunkten lange. Bitte rechnen Sie mit zusätzlichem Zeitbedarf für die Initialisierung des Debuggers, falls Sie viele JSP-Unterbrechungspunkte verwenden.
- Unterbrechungspunkte für statische Variablen in JSP-Deklarationsblöcken funktionieren nicht und verursachen gegebenenfalls andere Fehler mit Unterbrechungspunkten.
- Unterbrechungspunkteigenschaften (z. B. Trefferzählung, Kondition, ausgewählter Thread und Zurückstellungsrichtlinie für VM) werden für JSP-Unterbrechungspunkte nicht unterstützt.
- Keine Java-Unterbrechungspunkte im Debugger-Editor setzen: Java-Unterbrechungspunkte müssen im Java-Editor gesetzt werden. Der Editor des Debuggers darf hierzu nicht verwendet werden.
- Verwenden des Elements 'Quellendatei ändern' aus dem Kontextmenü der Debugsicht: Wenn Sie die Quellendatei ändern, die durch Verwendung des Kontextmenüelements Quellendatei ändern im Stack-Frame angezeigt wird, lässt sich die neue Datei möglicherweise nicht im Editor öffnen. Um dieses Problem zu umgehen, klicken Sie auf einen anderen Stack-Frame, und klicken Sie dann erneut auf den vorherigen Stack-Frame. Die neue Datei sollte sich dann im Editor öffnen lassen.
- Debug-Konsole: Die Hyperlinks zum Öffnen von Typen in der Debug-Konsole funktionieren nicht.
- Stack-Frame-Bezeichnungen nach Hot-Swap: Es ist möglich, dass nach dem Ausführen einer Hot-Swap-Ersetzung (Hot Swap Replace) manche Stack-Frames Bezeichnungen der folgenden Art aufweisen:
<Unbekannter Empfangstyp>(<unbekannter Deklarationstyp>).<unbekannter Methodenname>(<unbekannte Argumente>) Zeile: nicht verfügbar <unbekannte Zeilennummer>In diesem Fall erhalten Sie die korrekten Bezeichnungen, wenn Sie zu einer anderen Perspektive umschalten und anschließend wieder zur Perspektive 'Debug' zurückwechseln.
- Ein JavaScript-Objekt steht erst dann zur Prüfung zur Verfügung, wenn der Konstruktor vollständig ausgeführt wurde: Sie können zwar die Ausführung des Konstruktors mit Hilfe von Step-Aktionen durchlaufen, aber die Untersuchung des erstellten Objekts ist erst dann möglich, nachdem der Konstruktor vollständig ausgeführt und beendet wurde.
- Step-Aktionen und Stack-Frames unterhalb des Stack-Frames der höchsten Ebene: Step-over- und Step-return-Aktionen werden bei JavaScript für andere Stack-Frames als den Stack-Frame der höchsten Ebene nicht unterstützt.
- JSP-Element include: Das Debug von JavaScript in einem JSP-Element include wird nicht unterstützt.
- Rekursive Aktionen mit einer Step-out-Aktion verlassen: Benutzer, die ein Debug von rekursiven JavaScript-Funktionen ausführen, werden feststellen, dass sie beim Verlassen einer rekursiven Funktion mit einer Step-out-Aktion wieder zur höchsten Ausführungsebene zurückkehren.
- Erweitern Sie keine Objekte, die writer- oder inputStream-Variablen enthalten: Beim Überprüfen von JavaScript-Objekten werden Benutzer dazu angehalten, Objekte mit den Variablen writer oder inputStream nicht zu erweitern. Dies würde sonst dazu führen, dass der Debugger nicht reagiert.
- Testumgebung JavaScript-Debug funktioniert nicht bei Verwendung der WebSphere Version 5.0-Testumgebung. Dieser Fehler wurde unter APAR #PQ73036 behoben.
- Das Importieren oder Löschen einer Datenbank in der Datendefinitionssicht kann zum Verlust von gesetzten Unterbrechungspunkten führen: Wenn Sie ein Debug einer gespeicherten SQL-Prozedur ausführen, bevor Sie die Datenbank in einen Ordner in der Datendefinitionssicht importieren, und die Datenbank anschließend importieren, gehen alle erstellten Zeilenunterbrechungspunkte verloren. Nach dem Import der Datenbank verwendet der Debugger diesen Ordner, um die Quelle anzuzeigen. Wenn Sie die importierten Datenbankinformationen löschen, gehen beim nächsten Versuch, ein Debug der gespeicherten SQL-Prozedur auszuführen, die Unterbrechungspunktinformationen ebenfalls verloren. Hierdurch werden nicht die Unterbrechungspunkte wieder hergestellt, die beim ersten Import der Datenbank verloren gingen.
Zur Vermeidung dieses Problems empfiehlt es sich, die Datenbank zu importieren, bevor Sie ein Debug einer gespeicherten Prozedur ausführen.
- Debug von gespeicherten Java-Prozeduren wird nicht unterstützt: Der Editor ermöglicht Ihnen das Hinzufügen von Unterbrechungspunkten zum Quellcode einer gespeicherten Java-Prozedur. Diese Unterbrechungspunkte werden jedoch ignoriert, weil das Debug einer gespeicherten Java-Prozedur momentan noch nicht unterstützt wird.
- Begrenzte Namen für gespeicherte Prozeduren: Der Debugger für gespeicherte SQL-Prozeduren bietet eingeschränkte Unterstützung für gespeicherte Prozeduren mit begrenzten Schema- oder Prozedurnamen. Derartige Prozeduren müssen vom Startkonfigurationsdialog gestartet werden, nicht vom Kontextmenü in der Sicht 'Datendefinition'.
- Unterstützung mehrerer aktiver und gleichzeitig geöffneter Sitzungen des Debuggers für gespeicherte SQL-Prozeduren: In Version 5.0 dieses Produkts war es nicht möglich, zur gleichen Zeit mehr als eine aktive Sitzung des Debuggers für gespeicherte SQL-Prozeduren zu öffnen. Diese Einschränkung gilt ab einschließlich Version 5.0.1 sowie den späteren Versionen dieses Produkts nicht mehr.
- Gespeicherte Prozeduren mit 'FOR BIT DATA'-Argumenten: Für gespeicherte Prozeduren, die Argumente mit dem Attribut 'FOR BIT DATA' haben, kann kein Debug mit dem WebSphere Studio-Debugger für gespeicherte SQL-Prozeduren ausgeführt werden.
- Die im Early Availability-Produkt erstellte Startkonfiguration wird möglicherweise im vorliegenden Produkt nicht erkannt: Wenn Sie die Early Availability-Version dieses Produkts installiert und damit eine Startkonfiguration für den Debugger für gespeicherte Prozeduren erstellt haben, werden die Startkonfigurationseinstellungen möglicherweise nicht erkannt, wenn der Debugger mit der aktuellen Version dieses Produkts verwendet wird. Startkonfigurationseinstellungen, die in der Early Availability-Version gespeichert wurden, springen beim Öffnen in der aktuellen Version dieses Produkts möglicherweise auf die Standardwerte zurück.
Beachten Sie folgende Punkte, wenn Sie einen Server im Debug-Modus ausführen wollen:
- Der Start und die Ausführung der Server ist möglicherweise langsamer als in einem anderen (nicht für das Debug gedachten) Modus.
- WebSphere Application Server braucht wesentlich länger zum Kompilieren von JSP-Seiten.
Informationen zu den bekannten Problemen und Einschränkungen in Verbindung mit den Java-Entwicklungstools enthalten die Release-Informationen zu den Java Development Tools (JDT) und der Workbench (IDE). Diese können über eine Verknüpfung in der Readme-Hauptdatei des Produkts aufgerufen werden, die zusammen mit diesem Produkt installiert wurde.
- BiDi-Einschränkung (Bidirektional): Sie können den Debugger-Editor nicht verwenden, wenn Sie JSPs debuggen, die in einer anderen als der nativen Codepage codiert wurden.
- Compilersprachen-Debugger:
- Der Compilersprachen-Debugger unterstützt auf Einzelbytesystemen (SBCS) nicht Anwendungsnamen bzw. das Übergeben von Programmparametern, die Zeichen über 0x7F enthalten.
- Die Verwendung von landessprachlichen (typographischen) Zeichen in den Namen und Argumenten von zu debuggendem Code wird nicht unterstützt.
Wenn Sie ein Debug einer gespeicherten SQL-Prozedur auf einer lokalen Datenbank ausführen, wird möglicherweise der Fehler mit der Nummer SQL1224N angezeigt:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032
(COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI-Treiber] SQL1224N Ein Datenbankagent konnte nicht zur Bearbeitung einer Anforderung gestartet werden oder wurde als Reaktion auf das Herunterfahren eines Datenbanksystems oder auf einen verbindlichen Befehl beendet. SQLSTATE=55032)
Dieser Fehler wird durch ein Problem im Linux-Kernel ausgelöst (Bugzilla für Linux-Kernel Programmfehler #351). Die folgenden Anweisungen ermöglichen eine Umgehung, bei der an Stelle der Call Level Interface (CLI) die TCPIP-Verbindungsmethode von DB2 (als Loopback-Adresse) verwendet wird. Diese Prozedur ermöglicht dem Debugger die Verwendung desselben Datenbankaliasnamen wie zuvor:
- Wurde kein Port für ferne DB2-Clients eingerichtet, erstellen Sie im Verzeichnis /etc/services einen TCP/IP-Port (zum Beispiel db2cdb2inst1 50000/tcp # Port für DB2-Verbindungsservice). Es kann ein vorhandener Port für ferne DB2-Clients verwendet werden.
Zum Ausführen der Schritte 2 bis 7 müssen Sie als DB2-Exemplareigner angemeldet sein.
- Konfigurieren Sie den Datenbankmanager, um den Verbindungsmanager für das TCP/IP-Übertragungsprotokoll zu starten. Falls Sie nicht sicher sind, ob dies bereits erfolgt ist, geben Sie den folgenden Befehl aus:
db2set db2commSollte die Ausgabe nicht das Schlüsselwort tcpip enthalten, müssen Sie den folgenden Befehl eingeben, damit die Registrierungsdatenbankvariable db2comm aktualisiert wird und künftig tcpip enthält:
db2set db2comm=<namen vorhandener protokolle>,tcpipDie Registrierungsdatenbankvariable db2comm legt fest, welcher Verbindungsmanager von welchem Protokoll aktiviert wird, wenn der Datenbankmanager gestartet wird. Diese Variable kann für mehrere Übertragungsprotokolle definiert werden, indem die einzelnen Schlüsselwörter wie in dem folgenden Beispiel mit Kommas voneinander getrennt werden: db2set db2comm=tcpip,appc.
Damit die Verbindungsmanager für diejenigen Protokolle gestartet werden, die durch den Registrierungsparameter db2comm angegeben werden, müssen Sie den Befehl db2start erneut ausgeben. Da DB2 weiter unten in Schritt 7 neu gestartet wird, kann zum jetzigen Zeitpunkt darauf verzichtet werden.
.- Aktualisieren Sie den Parameter SVCENAME für die Datenbankkonfiguration mit dem Namen des Verbindungsservices, der in /etc/services definiert wurde (Schritt 1).
Um die aktuelle Einstellung für den Parameter SVCENAME zu prüfen, geben Sie den folgenden Befehl ein:
db2 get dbm cfg | grep -i svcenameFalls die aktuelle Einstellung von SVCENAME aktualisiert werden soll, geben Sie den folgenden Befehl ein:
db2 update dbm cfg using svcename <name des verbindungsservices>Hierbei gilt, dass bei <name des verbindungsservices> die Groß-/Kleinschreibung berücksichtigt werden und mit dem Namen des Serviceports übereinstimmen muss, den Sie in /etc/services angegeben haben (zum Beispiel db2 update dbm cfg using svcename db2cdb2inst1).
Die Aktualisierung der Datenbankmanagerkonfiguration tritt erst nach der nächsten Ausgabe des Befehls db2start in Kraft. Dies erfolgt weiter unten in Schritt 7.
- Katalogisieren Sie den Loopback-Knoten, indem Sie den folgenden Befehl eingeben:
db2 catalog tcpip node <knotenname> remote 127.0.0.1 server <name des verbindungsservices>Hierbei ist <knotenname> ein lokaler Aliasname für den Knoten, der katalogisiert werden soll. Dies ist beliebiger Name auf der Workstation, der den Knoten kennzeichnet (zum Beispiel db2 catalog tcpip node meinknoten remote 127.0.0.1 server db2cdb2inst1).
Um zu prüfen, ob der Katalogisierungsbefehl korrekt funktioniert hat, geben Sie den folgenden Befehl aus:
db2 list node directoryDie Ausgabe, die auf diesen Befehl erfolgt, sieht folgendermaßen aus (Leerzeilen wurden zwecks besserer Lesbarkeit entfernt):
Knotenverzeichnis
Anzahl von Einträgen im Verzeichnis = 1
Knoten 1 - Eintrag:
Knotenname = MEINKNOTEN
Kommentar =
Protokoll = TCPIP
Hostname = 127.0.0.1
Servicename = db2cdb2inst1- Katalogisieren Sie die Datenbank wie folgt. Beachten Sie die unten angegebenen Befehle zum Generieren einer Beispielausgabe, um die Auswirkungen jedes einzelnen Befehls zu verfolgen:
- db2 catalog db <datenbankname> as <aliasname der datenbank>
- db2 uncatalog db <datenbankname>
- db2 catalog db <aliasname der datenbank> as <datenbankname> at node <knotenname>
Beispiel:
db2 catalog db WAS as WASLOOP
db2 uncatalog db WAS
db2 catalog db WASLOOP as WAS at node MEINKNOTENHinweise:
- Der Aliasname der Datenbank kann jeder beliebiger Name sein. Er darf jedoch nicht nicht identisch mit dem Namen der Datenbank sein.
- Falls Sie die Datenbank nicht korrekt katalogisiert haben, wird der Fehler mit der Nummer SQL1334N gemeldet.
- Die Schritte 5 a bis 5 c müssen für jede Datenbank wiederholt werden, auf der Sie ein Debug für eine gespeicherte Prozedur ausführen wollen.
Beispielausgabe für die Schritte 5 a bis 5 c
Vor Schritt 5 a wurde bereits eine lokale Datenbank mit dem Namen WAS erstellt. Der Befehl db2 list db directory führt zu folgender Ausgabe:
Systemdatenbankverzeichnis
Anzahl von Einträgen im Verzeichnis = 1
Datenbank 1 - Eintrag:
Datenbankaliasname = WAS
Datenbankname = WAS
Lokales Datenbankverzeichnis = /home/ctsui
Datenbankreleasestufe = 9.00
Kommentar =
Verzeichniseintragstyp = Indirekt
Katalogknotennummer = 0Nach Schritt 5 a hat die Eingabe des Befehls db2 list db directory die folgende Ausgabe zur Folge:
Systemdatenbankverzeichnis
Anzahl von Einträgen im Verzeichnis = 2
Datenbank 1 - Eintrag:
Datenbankaliasname = WAS
Datenbankname = WAS
Lokales Datenbankverzeichnis = /home/ctsui
Datenbankreleasestufe = 9.00
Kommentar =
Verzeichniseintragstyp = Indirekt
Katalogknotennummer = 0
Datenbank 2 - Eintrag:
Datenbankaliasname = WASLOOP
Datenbankname = WAS
Lokales Datenbankverzeichnis = /home/ctsui
Datenbankreleasestufe = 9.00
Kommentar =
Verzeichniseintragstyp = Indirekt
Katalogknotennummer = 0Nach Schritt 5 b hat die Eingabe des Befehls db2 list db directory die folgende Ausgabe zur Folge:
Systemdatenbankverzeichnis
Anzahl von Einträgen im Verzeichnis = 1
Datenbank 1 - Eintrag:
Datenbankaliasname = WASLOOP
Datenbankname = WAS
Lokales Datenbankverzeichnis = /home/ctsui
Datenbankreleasestufe = 9.00
Kommentar =
Verzeichniseintragstyp = Indirekt
Katalogknotennummer = 0Nach Schritt 5 c hat die Eingabe des Befehls db2 list db directory die folgende Ausgabe zur Folge:
Systemdatenbankverzeichnis
Anzahl von Einträgen im Verzeichnis = 2
Datenbank 1 - Eintrag:
Datenbankaliasname = WAS
Datenbankname = WASLOOP
Knotenname = MEINKNOTEN
Datenbankreleasestufe = 9.00
Kommentar =
Verzeichniseintragstyp = Fern
Katalogknotennummer = -1
Datenbank 2 - Eintrag:
Datenbankaliasname = WASLOOP
Datenbankname = WAS
Lokales Datenbankverzeichnis = /home/ctsui
Datenbankreleasestufe = 9.00
Kommentar =
Verzeichniseintragstyp = Indirekt
Katalogknotennummer = 0
Um zu prüfen, ob der Befehl catalog db korrekt funktioniert hat, geben Sie die folgenden zwei Befehle aus (und beachten Sie die Beispielausgabe unten):
db2 connect to wasloop
db2 connect to wasHierbei sollte db2 connect to wasloop die Verbindungsinformationen ausgeben und db2 connect to was sollte SQL1403N angeben.
Beispielausgabe des Befehls db2 connect to wasloop:
Databanktverbindungsinformationen
SystemdatenbankverzeichnisDatenbankserver = DB2/6000 6.1.0
SQL- Berechtigungs-ID = CTSUI
Lokaler Datenbankaliasname = WASLOOPBeispielausgabe des Befehls db2 connect to was:
SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004
(SQL1403N Der angegebene Benutzername und/oder das angegebene Kennwort sind falsch. SQLSTATE=08004- Aktualisieren Sie das Authentifizierungsverfahren zu Clientauthentifizierung. Geben Sie den folgenden Befehl ein:
db2 update dbm cfg using authentication client
Um zu prüfen, ob der Befehl korrekt funktioniert hat, zeigen Sie die neuen Einstellungen durch Eingabe des folgenden Befehls an:
db2 get dbm cfg
Beispielausgabe:
....
Authentifizierung des Datenbankmanagers (AUTHENTIFIZIERUNG) = CLIENT
....- Starten Sie DB2 neu, damit der Verzeichniscache aktualisiert wird. Beispiel:
db2stop
db2start- Bei WAS ist es nicht erforderlich, die Datei 'admin.config' zu aktualisieren. Bei einer Websphere-Anwendung ist es nicht erforderlich, die vorhandene Konfiguration für die Datenquelle zu ändern.
- Wenn Sie die Datenbank freigeben wollen, geben Sie die folgenden Befehlsfolgen ein:
- db2 attach to <knotenname> user <benutzer_id> using <kennwort>
- db2 drop db <datenbankname>
Beispiel:
db2 attach to MEINKNOTEN user meine_id using mein_kennwort
db2 drop db WAS
Beim Ausführen von Hot-Swap während des Debug mit der J9 JVM wird ein Dialogfenster mit dem Inhalt Veraltete Methoden im Stack angezeigt, falls sich SQLJ-Methoden im Stack für Aufrufe befinden. Ist der Hot-Swap für eien SQLJ-Klasse erfolgt, wird die Klasse in der JVM neu geladen, aber der neue Code wird erst dann ausgeführt, wenn eine Methode in der Klasse aufgerufen wird.
Wenn Sie einen Hot-Swap für eine SQLJ-Klasse ausführen, funktionieren möglicherweise während der aktuellen Debugsitzung die SQLJ-Unterbrechungspunkte für diese Klasse nicht.
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved. (C) Copyright IBM Deutschland GmbH 2000, 2003. Alle Rechte vorbehalten.