WebSphere Application Server debug limitations
Debugging Web objects
- Java communication timeouts may need to be increased before performing a debug on server: To increase the Java timeouts, choose Window > Preferences from the workbench menu bar. Expand the Java node and click Debug. In the Debug preference page, increase both of the Communication timeouts (it is recommended that you at least double the default values). If the timeouts are not increased, the debugger will appear to hang when you perform a debug on server. The workbench log file will also contain org.eclipse.jdi.TimeoutException tracebacks.
- 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.
- 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.- Drop to Frame is not supported: After you launch a debug session for a Web object, you perform standard debug actions using the Java Development Tools (JDT) Debugger. However, the JDT Debugger Drop to Frame action is not supported or available when a debug session is launched with the WebSphere Application Server debug adapter.
- When debugging Java, you may receive a TimeoutException error in the Console view. If this happens, increasing the amount of time for debugger timeout can prevent the error. To increase the amount of time for debugger timeout, select Window > Preferences from the workbench menu bar to open the Preferences dialog box. In this dialog box, open the Java node and select the Run/Debug node. In the resulting Debug preference page, increase the value of the Debugger timeout field in the Communication section.
- Deprecated section in Java and Mixed Language Debug preference page: In the Java and Mixed Language Debug preference page, the Performance section (Stop at the first file name match when search for source check box) is deprecated and replaced by the Search for duplicate source files on the path check box in the Edit Source Lookup Path dialog.
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.
Hot Method Replace
- Changes to source that affect the shape of the class are not supported. This means that changes to method bodies will be hot replaced, while the following are examples of changes that will not be hot replaced:
- changes to class structure, such as the removal/addition of methods
- modification of class variables
- changes to inner classes
- Changes to the code in the bottom stack frame (the main(...) method) cannot be hot replaced.
- JSP Debugging does not support hot method replace of Java code.
Related concepts
Hot Method Replace for debugging Java applications
Hot Method Replace for debugging applications on WebSphere Application Servers
Related reference
Java and mixed language debug limitations