# Debugging Your Application

You can use the WebLogic Workshop integrated debugger to debug your application. The debugger allows you to set breakpoints, step through your code line-by-line, view local variables, set watches on variables, and view the call stack and exception information.

## Workshop Test Browser

In order to debug an application, you must have a way to exercise the application as a real client would. WebLogic Workshop includes a Test Browser in which you may test Workshop web applications and web servcies. When you run a web application or web service, the Test Browser automatically loads Test View, a tool for exercising the application.

## Testing with Debugging

To start the debugger, click the Start button on the toolbar or press Ctrl-F5. To pause debugging, click the Pause button on the toolbar. To stop debugging, click the Stop button on the toolbar.

When the debugger is started, the WebLogic Workshop Debugger command window is opened for the debugger proxy. This window must remain open in order to use the debugger. If you close this window, your breakpoints will not be hit when you test your application.

While your application is running in the debugger, it is unavailable to clients other than the Test Browser.

## Breakpoints

To clear all breakpoints at once including exception breakpoints in the project, click the Clear All Breakpoints button on the toolbar, or press Ctrl-F9.

You can also disable breakpoints, which prevents the debugger from stopping at them, but doesn't delete them from, so that they're easy to re-enable. To disable all breakpoints, select Disable All Breakpoints from the Debug menu or press Ctrl-Shift-B. To enable all breakpoints, select Enable All Breakpoints from the Debug menu or press Ctrl-B.

#### Line Breakpoints

You can set a breakpoint in your code to halt execution on that line, immediately before it is executed. You can then examine variable values and/or the call stack or set other break points.

To set or remove a breakpoint, go to Source View and put the cursor on the line on which you want to break. Click the Toggle Breakpoint button on the toolbar. You can also toggle a breakpoint by pressing F9, by clicking in the gray edge to the left of the line numbers in Source View, or by right-clicking on the line of source code and selecting Toggle Breakpoint from the context menu that appears.

#### Exception Breakpoints

You can also set breakpoints that are triggered when exceptions occur. To set an exception breakpoint, select Debug-->Create Breakpoint, in the Create Breakpoint dialog, select the "Exception" radio button, and provide the fully qualified classname of the exception. The debugger will hit the breakpoint whenever an exception of that class or one of its subclasses is thrown. You can determine whether the breakpoint always needs to be hit when an exception occurs, or whether the breakpoint only needs to be hit when the exception is either caught or not caught. Exception breakpoints are not set for a specific line of code, so your code in not marked with a red circle and highlighting when you create one.

#### Method Breakpoints

Method breakpoints allow you to set a breakpoint that will be hit as soon as a particular method is called. To create a method breakpoint, select Debug-->Create Breakpoint, in the Create Breakpoint dialog, select the "Method" radio button. Enter the fully qualified class name that contains the method, and the method's name. If the method is overloaded, you may also include the argument list for the specific version on which you'd like to set a breakpoint. If the method is overloaded and you do not specify the argument list, method breakpoints will be set in all of the overloaded versions.

#### Taglib and JSP Breakpoints

When debugging JSP files, you may also right-click on a taglib tag in the source editor and choose Taglib Breakpoints from the context menu. This brings up a dialog that shows the implementing class for the taglib and allows you to set breakpoints on all of the taglib methods it implements.

Additionally, when setting breakpoints in a JSP file, the breakpoint icon will have a black X over it if the line is not a valid line for a breakpoint. You can still set the breakpoint, but you will not hit it when running the JSP. This feature is not available for other file types.

## Debugging Properties

There are several options that can be set for debugging on a project basis. To change them, pull up the project properties by either right-clicking the project folder in the Application tab and selecting Properties from the context menu, or by going to Tools-->Project Properties-->[Project_Name]. Then select Debugger in the tree on the left.

Smart debugging: Filters out classes that are part of the WebLogic Platform so that when you step, you stay in your own code. For example, if you step into a method that's part of WebLogic Server and that method eventually calls your own code, the debugger will step directly into your code. For web application projects, this should almost always be left on.

Build before debugging: For web applications, this property specifies that a build should be executed on the current file before running. For Java projects, the entire project is built before running.

Pause all threads after stepping: Controls whether all threads are visible after stepping in the debugger. All threads are always suspended after hitting a breakpoint, but by default only the thread in which you are stepping is visible. The default behavior provides better performance, but you cannot see the other threads in the threads window. If you choose not to suspend all threads after stepping, you can still view them on demand using the Pause command.

The following options apply only to Java and Control projects. For detailed information see How Do I: Debug a Java Project?

#### Create new process

Starts a Java Virtual Machine for the application when you click on Start.

Main class: The name of the class with the main method that should be run.

Parameters: Arguments that should be passed to the main method.

VM parameters: Arguments that should be passed to the virtual machine when it starts. These include -D and -X VM options.

Home directory: The directory in which to start the Java application.

Application classpath: Classpath the virtual machine should use.

Automatically append Library JARs: In addition to the classpath specified above, add all the JARs that are shown in the Libraries folder in the Application window.

Automatically append server classpath: In addition to the classpath specified above, add all the JARs that are shown "Default server classpath" list in Tools-->WebLogic Server-->Server Properties.

#### Attach to process

Attaches to a Java Virtual Machine that is already running and is configured to accept a debugger when you click on Start.

Socket: Connects to the virtual machine over the TCP/IP connector. You must specify the port on which the VM is listening. If blank, the server defaults to localhost.

Shared memory: Connects to the virtual machine over the shared memory connector. You must specify the memory address on which the VM is listening.

### Using the Debugging Commands

Once execution is halted on a breakpoint, you can use one of the following commands to continue executing your code with the debugger. All of these commands are available on the toolbar and on the Debug menu.

- Step Into: The Step Into command continues execution line-by-line, beginning with the next line of code. Use this command if you want to debug your code one line at a time.
- Step Over: The Step Over command executes a method call without debugging that method, and halts execution on the next line. Use this command if you know that the code in a method works and you don't need to step into it.
- Step Out: The Step Out command finishes executing a method and returns execution to the procedure that called it, halting on the line immediately following the method call. Use this command if you have stepped into a method and you don't want to continue stepping all the way through it.
- Continue: The Continue command resumes execution until another breakpoint is encountered or the procedure has completed.
- Export Threads: The Export Threads command, found in the Debug menu, creates and opens a text file that contains the call stacks of all of the threads that are running. This is a convenient way to save or share the current threads in the event of a deadlock or other threading problem. The command is only active when the debugger has thread information.

Note that if you step into a line that contains more than one statement, all of the statements on that line will be executed when you step to the next line.

## Using the Debug Windows

The debug windows provide information about values and conditions in your code while you're running it in the debugger.

To view one of the debug windows, choose Debug Windows from the View menu, and select the desired window.

### The Locals Window

The Locals window automatically shows variables that are in scope as you execute your code in the debugger. You can modify the value of a primitive-type variable here while you are debugging.

You can expand entries for objects in the Locals window to view their members.

Some variable types have multiple views available in the Locals window. A small list of examples include:

- int: May be viewed and edited as a decimal integer or hexidecimal integer.
- char: May be viewed and edited as a character, Unicode escape, decimal integer, or hexidecimal integer.
- java.lang.StringBuffer: May be viewed showing just its contents as a String, its length, and its capacity, or with the default view showing its internal data structures.
- javax.servlet.http.HttpServletRequest: May be viewed showing attributes and other fields as simple name-value pairs, or with the default view showing its internal data structures.

To determine what other views are available and to switch to a different view, simply right-click on either the variable's name or value in the Locals window and look in the View As context menu. Note that the default view of internal data structures will be the only view available for some types.

### The Watch Window

You can use the Watch window to observe how the value of a particular variable changes as you're debugging. To set a watch, simply type the name of the variable into the Watch window.

Static classes must be fully qualified to be viewed in the Watch window.

### The Stream Window

The Stream Window is only active when doing JSP debugging and shows the output stream that the JSP is generating to send back to the Browser

### The Immediate Window

The Immediate window allows you to execute arbitrary code while debugging, with the following restrictions:

1. You cannot create new classes, Interfaces, or methods, or instantiate new object instances.
2. You cannot use the instanceof operator.
3. You cannot use .class syntax, such as Class c = java.lang.Object.class.
4. The value shown after clicking Evaluate will be the result of the last statement in the text field.
5. Static classes must be fully qualified.
6. If an object has a member variable and method with the same name, the variable is accessible but the method cannot be called.

### The Call Stack Window

The call stack shows the methods that have been called in order to reach the point at which execution is halted in the debugger. The methods are listed from most recently called to first called. You can also think in terms of each call being nested within the method below it on the call stack.

You can click on a method in the call stack to navigate to that method in Source View. This will also show the local variables available for that call stack, and reevaluate any watches within selected stack frame as well.

### The Threads Window

The Threads window shows information about the currently executing threads. You can click on stack frames to navigate to that method and refresh the Local and Watch windows in that stack frame. If you switch the selected thread and then use any of the step commands, you will step in that thread.

### The Breakpoints Window

The Breakpoints window lists the breakpoints that are currently set in your code by line number as well as the exception and method breakpoints. You can specify conditions under which each breakpoint should be hit in the Conditions column. You may also enable and disable individual breakpoints by using the checkboxes.

## Remote Debugging

If you're developing against a remote server, you can also debug against that remote server. Breakpoints and other debugging information will be stored on the local machine. For more information on pointing to a remote server, see How Do I: Use a Remote WebLogic Server During Development?

## Debugging JSP Pages

Be aware that browser caching is always turned off when you are debugging. To turn caching on while you are debugging, place the following scriptlet in your JSP pages.

        <%
            response.setHeader( "Cache-Control", null );
        %>

Note that browser caching is the default behavior when your web application is deployed to a production server. You do not need to take special measures, such as the scriptlet above, to turn on caching on a production server.

## Debugging Unrunnable Files

Some files cannot be directly run by WebLogic Workshop, e.g., servlets, custom Java controls, JAVA files, etc., nevertheless you can still set and hit breakpoint in these files. For example, to debug a servlet, set breakpoints in the servlet source code, add a JSP page to your project, run that JSP page (this will start the debugging process), and then enter the servlet's URL directly into the browser's address bar. You will now be able to halt at breakpoints in the servlet code.

To debug custom Java controls or JAVA files, set breakpoints in the source code of those files, and then run a web service or some other runnable file that calls into the Java control or JAVA file.

## Starting Two Debugging Proxies in the Same Domain

If you start two server instances in the same domain (for example, using the start up script [BEA_HOME]/weblogic81/samples/domains/portal/startWebLogic.cmd), the second server will fail with a TransportException.

        ERROR: Proxy already running...
        weblogic.debugging.comm.TransportException
        at weblogic.debugging.comm.ServerConnectInfo.createTransport()Lweblogic.
        debugging.comm.CommTransport;(ServerConnectInfo.java:63)

The failure is caused by the debugging proxy, which attempts to open the same server socket port already used by the first server.

To start the second server running on a different port, send a port number parameter to (1) the WebLogic Workshop IDE, (2) the server, and (3) the debugger.

### (1) To Set the Port Number on the WebLogic Workshop IDE

Add the following parameter to [BEA_HOME]\weblogic81\workshop\workshop.cfg.

-Dworkshop.debugProxyPort=PORT_NUMBER

### (2) To Set the Port Number on the Server

Add the following parameter to the server startup script (for example, [BEA_HOME]\weblogic81\samples\domains\workshop\startWebLogic.cmd/.sh).

-Dworkshop.debugProxyPort=PORT_NUMBER

### (3) To Set the Port Number on the Debugger Process

##

Add the following parameter to the server startup script (for example, [BEA_HOME]\weblogic81\samples\domains\workshop\startWebLogic.cmd/.sh).

-serverport=PORT_NUMBER

Related Topics

How Do I: Debug a Java Project?

How Do I: Debug an Application?

How Do I: Debug an Application on a Remote Production Server?