WebSphere Application Server debug limitations

Debugging Web objects

• Java™ communication timeout settings might need to be increased before performing a debug on server: If you are having trouble getting the debugger to connect to your application, you might need to increase your Java debug timeout settings. To determine if you are having this problem, check your <workspace>\.metadata\.log file for the existence of org.eclipse.jdi.TimeoutException messages. To increase the Java timeout settings, 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 (Debugger timeout (ms) and Launch timeout (ms) - it is recommended that you at least double the default values for these two fields). If the timeout settings are not increased, the debugger will hang when you perform a debug on server.

  For applications running on WebSphere Application Server Version 6.0 or later, you can then attempt to reconnect by right-clicking the server in the Servers view, and selecting Reconnect debug process from the pop-up menu.

• Source Not Found editor might close unexpectedly: In some cases, the debugger Source Not Found editor, which provides a button with which you can edit the source lookup path, might close unexpectedly. To edit the source lookup path, right-click on an object in the Debug view and select Edit Source Lookup from the pop-up menu.
• 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.
• Debugging JSP pages:
  • When debugging JSP pages, EL (expression language) is not supported. For example, you cannot step into a JSP line that contains EL.
  • Step-by-step debug will not work for JSP pages that do not contain any executable code.
  • Inspecting and displaying JSP variables and expressions is not supported.
  • Run to line is not supported in JSP pages.
  • Setting JSP file breakpoints might be slow. If you have many JSP file breakpoints, the debugger will take extra time to initialize.
  • Breakpoints on static variables in JSP declaration blocks will not work and might cause other breakpoint problems.
• 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.
• When debugging Java, you might receive a TimeoutException error in the Console view. If this error message opens, 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.
• Source lookup path problem when attaching to WebSphere Application Server v7.0: When you attach to WebSphere Application Server v7.0 using the WebSphere Application Server launch configuration, the default source lookup path may contain the src.jar file from the WebSphere Application Server v6.1 stub Java runtime for JRE source lookup. You can edit the source lookup path to remove the src.jar file from WebSphere Application Server v6.1 stub and add the src.jar file from WebSphere Application Server v7.0 JRE.

JSP Page Debugging:

• 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.)

JSP File Breakpoints Migration:

• If you are migrating a workspace from an older version of WebSphere Application Server to a newer version, you will need to migrate your JSP file breakpoints or recreate them.
• To migrate JSP file breakpoints, select the breakpoints to migrate in the Migration wizard that opens automatically on start-up of the new workspace, or invoke the Migration wizard manually by selecting the "Run migration" button in the toolbar of the Migration Results view.
• To open the Migration Results view, select Window > Show View > Other... and search for the view under the Migration node.
• Imported obsolete JSP file breakpoints are not migrated automatically. Migration wizard will need to be invoked manually to migrate the breakpoints.

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 these are examples of changes that will not be hot replaced:
  • changes to class structure, such as the removal/addition of methods, and changes to the signature of an existing method.
  • modification of class variables
  • changes to inner classes

  If you change the shape of the class by adding or removing a field or method, or as described above, you might receive an error with the message "Scheme change not implemented", as pictured below:

  

  This error indicates that you have performed an unsupported hot code replacement, and the change was not processed by the virtual machine. You might also see an "(out of synch)" message on the stack frames or threads in the debug view. These messages should disappear if you undo the unsupported change.

• Changes to the code in the bottom stack frame (the main(...) method) cannot be hot replaced.
• Changes to the code that is directly referenced by native methods cannot be hot replaced.

  In the debug view, all native methods on the stack have the notation "[native method]" appended to the stack frame, as in the screenshot below:

  For example, imagine that the debugger is currently suspended in methodA, called from methodB, and you make a change in the body of methodA. The hot code replacement will not succeed if methodB is a native method. You will not be able to replace methods invoked through reflection while you are suspended in these methods. Some examples of methods invoked through reflection, are constructors called through Class.newInstance() and Method.invoke().

  If you change the body of a method invoked by native code while the debugger is suspended there, you might see an error dialog titled "Obsolete Methods on the Stack" like the one below:

  

  Continuing the previous example, since methodA has been changed, the original methodA before the change is now obsolete. However, the virtual machine is unable to execute the new methodA because it is called from a native method, and so will continue to use the old, now obsolete contents of methodA.

• JSP page debugging does not support hot method replace of Java code.

Bidirectional (BIDI/BiDi) language limitations