1.0 Introduction
2.0 Known problems and limitations
2.1 Web Development Environment
2.2 WebSphere Application Server Debug Adapter
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 Compiled language debugger
2.8 National language limitations
The debuggers in WebSphere Studio provide the tooling necessary to debug Web applications, server-side JavaScript, Java, SQL Stored Procedures, and compiled languages. This readme file describes the known problems and limitations that are associated with the WebSphere Studio debuggers.
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.
- 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.
- 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.
- 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.
- 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.
- 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 Version 5.0.1 of this product.
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.
- Missing debug attributes: The debugger requires that class files be compiled with debug attributes if it is to be able to display line numbers and local variables. Quite often, class libraries (for example, "
rt.jar
") are compiled without complete debug attributes, and thus local variables and method arguments for those classes are not visible in the debugger.- Setting breakpoints: In general the debugger will not allow you to place breakpoints on lines of code that are not executable (comments, blank lines, etc.). However, there are some cases where the debugger will allow breakpoints on lines of code that are not executable. For example, the debugger will allow a breakpoint to be placed on a variable declaration that does not contain an initializer ("int x;"). Note that enabled breakpoints which are successfully installed on an executable line in a running (debuggable) VM are displayed with a checkmark. Breakpoints that are displayed without a checkmark are not installed in a running (debuggable) VM.
- Using Hot Code Replace: Hot code replace is supported on JDK 1.4.x VMs, and IBM J9 VMs. Hot code replace is limited to changes which do not effect the shape of a class. That is, changes within existing methods are supported, but the addition or removal of members is not supported. Hot code replace and stepping on JDK 1.4.0 VMs is unreliable. This appears to be a VM issue that should be fixed in later releases of the JDK.
- Debugging over slow connections: A global Java debug preference specifies the debugger timeout, which is the maximum amount of time the debugger waits for a response from the target VM after making a request of that VM. Slow connections may require that this value be increased. The timeout value can be edited from the Java > Debug preference page. Changing the timeout value only effects subsequently launched VM, not VMs that are already running.
- Updating of inspected values When inspecting the result of an evaluated expression in the debugger, it is important to note that the result displayed is the result of that expression at the time it was evaluated. For example, when inspecting a simple integer counter (primitive data type), the value displayed in the Expressions view is the value when the expression was evaluated. As the counter is changed in the running program, the inspected result will not change (since the view is not displaying the value bound to a variable - it is displaying the value of an expression, and the value of a primitive data type cannot change). However, if an expression results in an object, fields of that object will be updated in the inspector as they change in the running program (since the value bound to fields in an object can change).
- Stepping over native methods that perform I/O: When the debugger steps over native methods that perform I/O to
System.out
orSystem.err
, the output may not appear immediately unless the native performs a flush on the output buffer.
"Unable to find DLL" error: If starting a compiled debug session produces the Windows message "Unable to find DLL", remove the LOCPATH environment variable.
- 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.
Return to the main readme file