Table of Contents

Previous Section

Launching an Application for Debugging

You debug WebObjects applications using Project Builder, as described in the online book WebObjects Tools and Techniques. The executable you launch differs based on which language you used to write the application. This section tells you how to begin a debugging session for WebObjects applications written in each of the three available languages: WebScript, Java, and Objective-C.

Debugging WebScript

To debug WebScript code, you rely on log messages and trace statements described in the section "Debugging Techniques".

If you've written an application entirely in WebScript, you typically debug it by running NeXT_ROOT/NextLibrary/Executables/WODefaultApp from the Project Builder launch panel, as described in WebObjects Tools and Techniques. When you do, the output from the debugging and trace statements is displayed in the launch panel.

Debugging Java

The debugging strategy for Java applications is very similar to the strategy for debugging WebScript applications. Because the WebObjects Java bridge is incompatible with jdb, no Java debugger is supported for WebObjects. Instead, you can use the methods described in the section "Debugging Techniques" as well as System.out.println statements. Build the executable for your project using Project Builder, then launch that executable in the launch panel. Output from the debugging methods appears in the launch panel.

Debugging Objective-C

If all or part of your application is written in Objective-C, you can use the gdb debugger in Project Builder. For more information on debugging an Objective-C application with Project Builder, see Project Builder's online help.

If your application contains WebScript code as well as Objective-C code, you debug the WebScript portion using logWithFormat: and WOApplication trace statements as described in "Debugging Techniques".

Debugging Mixed Applications

When you build a WebObjects application project, the result is a .woa file package inside of the project directory. You may notice that this file package contains all of the application's components (including scripted components), and all other resources need to run the application, as well as the application executable itself.

When you're debugging an application, the executable uses the components from the project directory instead of those in the .woa package, so you can safely ignore the components placed inside of the .woa package. When you need to make a change, change the component in the project directory. When you run an application, it checks to see if its .woa package is inside of a project directory (that is, a directory that contains a file named PB.project). If it is, the application takes its scripted components from the project directory. This way, you can make any necessary changes to your scripts in Project Builder, and (once you have saved the scripts) your application automatically picks up your changes without your having to rebuild.

Table of Contents Next Section