The IBM Distributed Debugger (sometimes called the Integrated Remote Debugger) is a shared IBM product. It comes with WebSphere Application Server, WebSphere Studio, and VisualAge for Java. You can use it in all three of these products to debug Java servlets, JSP 0.91, and JSP 1.0.
This document discusses installing and using the Debugger with WebSphere Studio 3.01 or 3.02 to debug Studio files that are running on the WebSphere Application Server.
It contains the following topics:
Software requirements
Supported configurations
Installing the Debugger
Completing the configuration
Getting ready to debug
Debugging Studio files
Hints, Tips, and Known Issues
The Debugger lets you debug Java files, including JSPs, in your Studio projects while they are actually running on WebSphere Application Server. The following list shows the software you will need to use the Debugger with Studio.
We recommend that you upgrade to WebSphere Studio to version 3.01 or 3.02. The Debugger is not included in the Entry Edition of Studio ( the edition that you can download from the IBM web site ).
The following table shows which versions of WebSphere Application Server work with Studio to support the Debugger.
| WebSphere Studio Version |
WebSphere Application Server Version and Edition |
Debugger Supported? |
| 3.01 | 3.0 Advanced 3.0 Standard |
Yes |
| 3.01 Advanced 3.01 Standard |
Yes | |
| 3.02 Advanced | Yes | |
| 3.02 Standard | No | |
| 3.02 | 3.0 Advanced 3.0 Standard |
Yes |
| 3.01 Advanced 3.01 Standard |
Yes | |
| 3.02 Advanced | Yes | |
| 3.02 Standard | No |
Note: The Debugger does not currently work with Studio and WebSphere Application
Server 3.02 Standard Edition. If you try to start the Application Server 3.02
Debugger from Studio, you will receive an error message saying that no OLT Controller
has been defined, when there actually is one. This is will be fixed in a a future
release.
VisualAge for Java 3.0 includes version 8 of the Debugger and WebSphere Studio and WebSphere Application Server both include version 7. And, although Studio and the Application Server include the same version of the Debugger, they have mutually exclusive parts of the Debugger code. Also, the Debugger is an optional component when installing the Studio, but not when installing the Application Server.
Before you install the Debugger shipped with Studio (or with the Application
Server), check to see if you have already installed the Debugger shipped with
VisualAge for Java.
Remember, the Debugger will only be completely uninstalled when all its instances have been uninstalled.
Depending on the versions of Studio and Application Server you are running, you might have to do some additional configuration.
For WebSphere Application Server 3.0 and 3.01 with Studio 3.02
In order to debug Studio files on WebSphere Application Server 3.0 or 3.01 Standard and Advanced, you must make a change to Studio:
Note: As a result, some Debugger and JSP compile messages are not translated; they will display in English.
For WebSphere Application Server 3.02 Advanced
In order to debug on WebSphere Application Server 3.02, you must make a change to the Application Server's admin.config file:
com.ibm.ejs.sm.util.process.Nanny.path The location (path) of the Debugger will depend on which software you installed first on that machine:
For example, if the Application Server was installed first on a Windows NT
system, the entry might be:
com.ibm.ejs.sm.util.process.Nanny.path=e:\\WebSphere\\AppServer\\bin;
e:\\WebSphere\\AppServer\\bin;e:\\JDK11~1.7\\bin;e:\\sqllib\\bin;
e:\\sqllib\\function;e:\\ibmdebug\\bin
(Note: This entry should be on one line in your admin.config file.)
If you have both DB2 and the Application Server on the same machine and would like to have local access to DB2 when running the Debugger, you must copy the file db2jdbc.dll to db2jdbc_g.dll in \sqllib\bin directory (in the drive/directory where you installed DB2).
Before you start to debug your Studio files with the Debugger, verify your Studio and publishing setup.
Verify the Studio setup
When these conditions are met, the Debug options on the Project menu and the debug icon on the tool bar are enabled.
Verify publishing setup
In order for the Studio Debugger to remotely start an application server, the WebSphere Application Server Administration Console must be started and the application server must be stopped.
The files that you have selected are processed and published, and both the client and server-side Debugger processes are started.
To begin debugging, use a browser to request your files and run your application. The debug user interface (UI) will display on your desktop when the first Java or JSP file is processed.
Note: If your web application requires input, you must provide it so that the Java code will execute. If your request just returns HTML, it won't start the debug process.
The following information points out some of the known issues and helps you avoid common problems.
Keeping the Administration Console current
If Studio starts the OLT controller and application server, the WebSphere Application Server Administration Console will not always show the current state of objects. In particular, it will not reflect the current state of an object, if it did not cause the state change.
To see the current state of an object:
Starting the OLT Controller
We strongly recommend that you let Studio start the OLT Controller and application server for you. If you start OLT Controller and application server manually (instead of letting Studio do it), the OLT controller must be started first. Also, the application server must be started in debug mode.
Starting the debugging processes
With Studio 3.01, if you receive this message (and your Application Server is started):
Unable to start the remote debug processes on server <server>.
Please be sure that this machine is started and ready to receive debug commands.
Ensure that the hostname of the node in the Applications Server Console Topology matches the name of the publishing server in the Studio project. This name is case sensitive.
Debugging servlets and JSPs
The Debugger User Interface (UI) handles servlet and JSP file debug differently:
Servlets
If your servlet contains a service method, the Debugger UI will display the
source for your servlet and will stop at the first debuggable statement in its
service method. If your servlet does not contain a service method, the Debugger
will stop in the parent of your servlet (HttpServlet). You must then step into
your servlet's method (doGet, doPost, etc.) from the parent source.
JSPs
The Debugger UI will display your JSP source and will stop on the first JSP
source line.
Debugging JSP 1.0 files
The Debugger cannot automatically find the source for JSP 1.0 files and will prompt you for their location.
Debugging the Studio samples
To debug the Studio samples, they must be in a project whose properties are set for WebSphere Application Server version 3.0 and JSP version is 0.91. To verify this:
Closing the Debugger window
It is best not to close the Debugger window manually if you want to debug again. If you close the Debugger window, you will have to restart Studio before it will reappear. You will also have to restart the OLT Controller and application server.
Closing the JSP HTML Output window
The JSP HTML Output Window does not currently display the HTML generated during JSP debug stepping. You can safely close this window at any time.
Note: The term application server, in the context of the Administration Console Topology, refers to a particular application server process running in WebSphere Application Server. You can define more than one application server on your host machine. For example, Default Server is the name of an application server that is optionally created for you when you install. You can publish and run your Studio servlets and JSPs on the Default Server or on any other application server you define. You will debug these files wherever they are running.