Debugging Web Services
You can use the WebLogic Workshop integrated debugger to debug your web service. 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.
To use the debugger while testing your web service, click the Start and Debug button on the toolbar, or press F5. To stop debugging, click the Stop button on the toolbar.
When the debugger is running, you'll see a command window, titled WebLogic Workshop Debugger, 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 service.
While a web service is running in the debugger, it is unavailable to clients.
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 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 "trough" to the left of the line numbers on the left edge of the Source View window; or by right-clicking on the line of source code and selecting Set Breakpoint from the context menu that appears.
To clear all breakpoints in the project at once, click the Clear All Breakpoints button on the toolbar, or press Ctrl-Shift-F9.
The following image shows execution halted on a breakpoint in Source View:
If you set a breakpoint on a line that is not executed, such as a variable declaration, WebLogic Workshop will display a warning in the Output window that the breakpoint is invalid.
Note that if you add breakpoints to a file, the breakpoints will be lost if you close the file in the visual development environment.
Once you've halted execution 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.
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.
The Debug window provides information about values in your code while you're running it in the debugger.
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. The following image shows the individual array elements that make up the value of a StringBuffer object.
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. The following image shows variables in the Watch 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 double-click on a method in the call stack to navigate to that method in Source View.
The following image shows two methods on the call stack.
If you're developing against a remote server, you can also debug against that remote server. In the Preferences dialog, on the Paths tab, set the Name option to the name of the remote server and set the Port option to its specified port. Set the Config directory option to point to the directory that contains the server domain, and set the Domain option to the name of that domain.
Note: The remote server must have a valid machine name in order for you to debug against it. On a Linux system, you can use the hostname command to determine the machine name.
For more information on modifying your WebLogic Workshop preferences to point to a remote server, see How Do I: Create a New WebLogic Workshop-enabled WebLogic Server Domain?