Debuggers - release notes

1.0 Introduction
2.0 Known problems
   2.1 Web Development Environment
   2.2 WebSphere Application Server debugging
   2.3 JavaScript debugger
   2.4 SQL Stored Procedure debugger
   2.5 Test and deployment tools (server tools)
   2.6 Java Development Tools (JDT) debugger
   2.7 National language limitations
   2.8 SQL Stored Procedure debugger (Linux)
   2.9 SQLJ debugger

1.0 Introduction

The debuggers in WebSphere Studio provide the tooling necessary to debug Web applications, server-side JavaScript, Java, SQLJ, SQL Stored Procedures, and compiled languages. This readme file describes the known problems and limitations that are associated with the WebSphere Studio debuggers.

2.0 Known problems

2.1 Web Development Environment

JSP Debugging:

JSP files can be debugged when testing on a WebSphere Application Server. If you are testing on a Tomcat server, the debugger will not stop at JSP breakpoints.

Breakpoints can be set in JSP files within the following tags:

JSP scriptlets of the form: <% %>

JSP expressions of the form: <%= %>

JSP declarations of the form: <%! %>

jsp:useBean, jsp:getProperty, and jsp:setProperty tags

Custom tags

Breakpoints cannot be set for the following tag sets:

HTML code

JSP directives

All other standard JSP tags jsp:include, jsp:forward, etc.)

If you are migrating a workspace from an older version of WebSphere Studio to this version then you will need to delete your JSP breakpoints and recreate them.

2.2 WebSphere Application Server debugging

Step-by-step debug mode will fail for EJB home methods: If you use the WebSphere Application Server debug adapter to launch a debug session, step-by-step debug mode will not stop for EJB home methods. Use breakpoints if you want to debug these methods.

Step return from Java back to JavaScript is not supported: Use breakpoints if you want to be able to return back to your JavaScript code from Java.

Debugging JSPs:

Step-by-step debug will not work for JSPs that do not contain any executable code.

If you use the WebSphere Application Server Debug Adapter to launch a debug session, you cannot inspect or display JSP variables and expressions.

Run to line is not supported in JSPs.

Setting JSP breakpoints may be slow. Please allow extra time for the debugger to initialize if you have many JSP breakpoints.

Breakpoints on static variables in JSP declaration blocks will not work and may cause other breakpoint problems.

Breakpoint properties such as hit count, condition, selected thread, and VM suspend policy are not supported for JSP breakpoints.

Do not set Java breakpoints in the Debugger Editor: Java breakpoints must be set in the Java Editor and not in the Debugger Editor.

Using the Change Source File Debug view pop-up menu item: If you change the source file that is displayed by using the Change Source File popup menu item on the stack frame, the new file may not open in the editor. To work around this, click another stack frame and then click the original stack frame again. The new file should then open in the editor.

Debug console: In the Debug console, hyperlinks to open types will not work.

Stack frame labels after hot swap: If, after a hot code replace, some of the stack frames have labels like
<unknown receiving type>(<unknown declaring type>).<unknown method name>(<unknown arguments>) line: not available <unknown line number>
you can get the correct labels by switching to a different perspective and then back to the Debug perspective.

2.3 JavaScript debugger

A JavaScript object is not available for examination until its constructor is complete: You can step through the execution of the constructor, but you cannot examine the object being constructed until construction is complete (you have exited the constructor).

Stepping and stack frames below the top stack frame: Step over and step return of a stack frame other than the top stack frame is not supported for JavaScript.

JSP include: Debugging JavaScript in a JSP include is not supported.

Stepping out of recursive functions: Users debugging recursive JavaScript functions will find that when they step out of a recursive function, they return to the top execution level.

Do not expand objects containing writer or inputStream variables: When examining JavaScript objects, users are cautioned not to expand objects containing the variables writer or inputStream. This will cause the debugger to become unresponsive.

Test Environment: JavaScript debug will not work when using the WebSphere V5 Test Environment. This problem is fixed under APAR #PQ73036.

2.4 SQL Stored Procedure debugger

Importing or deleting database in Data Definition view can cause loss of set breakpoints: If you debug an SQL stored procedure before you import the database to a folder in the Data Definition view and then import the database, any line breakpoints you have created will be lost. Once you have imported the database, the debugger will use that folder to view the source. If you delete the imported database information, you will also lose the breakpoint information the next time you try to debug a SQL stored procedure. This will not restore breakpoints lost when the database was first imported.

We recommend that you import the database before debugging a stored procedure to avoid this problem.

Debugging Java stored procedures is not supported: The editor allows you to add breakpoints to the source code of a Java stored procedure. However, these breakpoints are ignored because the debugging of Java stored procedures is not yet supported.

Delimited stored procedure names: the SQL stored procedure debugger provides limited support for stored procedures with delimited schema or procedure names. Such procedures must be launched from the Launch Configuration dialog and not from the context menu in the Data Definition view.

Support for having more than one active SQL stored procedure debugger session open at the same time: In Version 5.0 of this product, you could not have more than one active SQL stored procedure debugger session open at one time. This restriction no longer applies in Versions 5.0.1 or greater of this product.

Stored Procedures with FOR BIT DATA arguments: Stored procedures which have arguments with the FOR BIT DATA attribute cannot be debugged with the WebSphere Studio SQL Stored Procedure debugger.

Launch configuration created in Early Availability product may not be recognized in current product: If you installed the Early Availability version of this product and created a Stored Procedure Debugger launch configuration with it, the launch configuration settings may not be recognized when it is used with the current version of this product. Launch configuration settings that were saved in the Early Availability version may revert back to default values when opened in the current version of the product.

2.5 Test and deployment tools (server tools)

Consider the following when deciding to run a server in debug mode:

Servers may start and run slower than running in non-debug mode.

WebSphere Application Server takes significantly longer to compile JSP pages.

2.6 Java Development Tools (JDT) debugger

Information about the known problems and limitations with the Java development tools is available in the Java development tools (JDT) release notes and in the Workbench (IDE) release notes. These are linked to from main product readme that installed with this product.

2.7 National language limitations

Bidirectional (BiDi) limitation: You will not be able to use the Debugger editor when debugging JSPs that have been encoded in a codepage other than the native codepage.

Compiled Language Debugger:

On single byte (SBCS) systems, the Compiled Language Debugger does not support program names or the passing of program parameters that contain characters above 0x7F.

The use of NL characters in debuggee names and debuggee arguments is not supported.

2.8 SQL Stored Procedure debugger (Linux)

When you are debugging an SQL Stored Procedure on a local database, it is possible to receive error number SQL1224N:

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

This is due to a problem in the Linux kernel (Linux kernel Bugzilla bug #351). The following instructions are a work-around that uses DB2's TCPIP connection method (as a loopback) instead of Call Level Interface (CLI). This procedure will allow the debugger to use the same database alias as before:

If a port for remote DB2 clients has not been set up, create a TCP/IP port in /etc/services, (for example, db2cdb2inst1 50000/tcp # DB2 connection service port). An existing port for remote DB2 clients may be used.
Steps 2 to 7 below require you log in as the DB2 instance owner.

Configure the database manager to start connection manager for the TCP/IP communication protocol. If you are not sure if this has already been done, issue the following command:
db2set db2comm

If the output does not contain the keyword tcpip, you need to enter the following command to update the db2comm registry variable to include tcpip:

db2set db2comm=<existing protocol names>,tcpip

The db2comm registry variable determines which protocol's connection manager will be enabled when the database manager is started. You can set this variable for multiple communication protocols by separating the keywords with commas, for example, db2set db2comm=tcpip,appc.

You need to re-issue the db2start command in order to start the connection managers for the protocols specified by the db2comm registry parameter. Since we will restart DB2 in step 7 below, there is no need to now.
.
Update the SVCENAME database manager configuration parameter with the connection service name defined in /etc/services (step 1).
To check the current setting of SVCENAME, enter the following command:

db2 get dbm cfg | grep -i svcename

If you need to update the setting of SVCENAME, enter the following command:

db2 update dbm cfg using svcename <connection service name>

where <connection service name> is case-sensitive and must match the name of the service port that you placed in /etc/services (for example, db2 update dbm cfg using svcename db2cdb2inst1).

The update of the database manager configuration will not be effective until the next db2start command is issued. We will do this in step 7 below.

Catalog the loopback node by entering the following command:
db2 catalog tcpip node <nodename> remote 127.0.0.1 server <connection service name>

where <nodename> is a local alias for the node to be cataloged. This is an arbitrary name on the workstation, used to identify the node (for example, db2 catalog tcpip node mynode remote 127.0.0.1 server db2cdb2inst1).

To verify that the catalog command worked properly, issue the following command:

db2 list node directory

A sample output of this command is (blank lines have been removed for legibility):

Node Directory Number of entries in the directory = 1 Node 1 entry: Node name = MYNODE Comment = Protocol = TCPIP Hostname = 127.0.0.1 Service name = db2cdb2inst1

Catalog the database as follows. See the commands given below to generate sample output if you wish to track the effects of each command:

db2 catalog db <database name> as <database alias>

db2 uncatalog db <database name>

db2 catalog db <database alias as <database name> at node <nodename>

for example,
db2 catalog db WAS as WASLOOP db2 uncatalog db WAS db2 catalog db WASLOOP as WAS at node MYNODE

Notes:

The database alias can be any name you want but it cannot be the same as the database name.

You will receive error number SQL1334N if you did not catalog the database correctly.

You need to repeat steps 5a to 5c for every database on which you wish to debug a stored procedure.

Sample output for steps 5a to 5c

Before step 5a, a local database named WAS has already been created. The command db2 list db directory has the following output:

System Database Directory Number of entries in the directory = 1 Database 1 entry: Database alias = WAS Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0

After step 5a, db2 list db directory has the following output:

System Database Directory Number of entries in the directory = 2 Database 1 entry: Database alias = WAS Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0 Database 2 entry: Database alias = WASLOOP Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0

After step 5b, db2 list db directory has the following output:

System Database Directory Number of entries in the directory = 1 Database 1 entry: Database alias = WASLOOP Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0

After step 5c, db2 list db directory has the following output:

System Database Directory Number of entries in the directory = 2 Database 1 entry: Database alias = WAS Database name = WASLOOP Node name = MYNODE Database release level = 9.00 Comment = Directory entry type = Remote Catalog node number = -1 Database 2 entry: Database alias = WASLOOP Database name = WAS Local database directory = /home/ctsui Database release level = 9.00 Comment = Directory entry type = Indirect Catalog node number = 0

To verify that the catalog db command worked properly, issue the following two commands (and see the sample output below):

db2 connect to wasloop db2 connect to was

where db2 connect to wasloop should print the connection information and db2 connect to was should give you SQL1403N.

Sample output of db2 connect to wasloop:

Database Connection Information System Database Directory Database server = DB2/6000 6.1.0 SQL authorization ID = CTSUI Local database alias = WASLOOP

Sample output of db2 connect to was:

SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004

Update the authentication mechanism to Client authentication. Enter the command:
db2 update dbm cfg using authentication client

To verify that the command worked properly, display the new setting with the following command:

db2 get dbm cfg

Sample output:

.... Database manager authentication (AUTHENTICATION) = CLIENT ....

Restart DB2 to refresh the directory cache. For example,
db2stop db2start

For WAS, there is no need to update the admin.config file. For a Websphere application, there is no need to change the existing datasource configuration.

If you want to drop the database, do the following:

db2 attach to <nodename> user <userid> using <password>

db2 drop db <database name>
for example, db2 attach to MYNODE user myid using mypasswd db2 drop db WAS

2.9 SQLJ debugger

When performing hot swap while debugging with the J9 JVM, if there are any SQLJ methods on the call stack, you will get an Obsolete methods on the stack dialog. If the hot swap was of an SQLJ class, the class will be reloaded in the JVM, but you will not see the new code being executed until the next time a method in the class is called.

If you hot swap an SQLJ class, SQLJ breakpoints may not work for this class during the current debug session.

Return to the main readme file