1.0 Introduction
2.0 Known problems
2.1 Web Development Environment
2.2 WebSphere Application Server debugging
2.3 JavaScript debugger
2.4 Test and deployment tools (server tools)
2.5 Java Development Tools (JDT) debugger
2.6 National language limitations
2.7 SQLJ debugger
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.
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.
- 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.
- 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.
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.
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.
- 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.
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
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.