Debugging in Hosted Mode

You will spend most of your development time working in hosted mode, which means that you are interacting with your GWT application without it having been translated into JavaScript. Anytime you edit, run, and debug applications from a Java integrated development environment (IDE), you are working in hosted mode. When running in hosted mode, the Java Virtual Machine (JVM) is actually executing your application code as compiled Java bytecode, using GWT plumbing to automate an embedded browser window. This means that the debugging facilities of your IDE are available to debug both your client-side GWT code and any server-side Java code as well. By remaining in this traditional "code-test-debug" cycle, hosted mode is by far the most productive way to develop your application quickly.

To launch a hosted mode session, run the

<module>

The shell script will first create a Development Shell window. The development shell runs a Tomcat instance to host server-side Java functionality. The window is used to capture debugging logs and exceptions from the application.

If you are not using the shell script, remember that in hosted mode, the GWT development shell looks for modules (and therefore client-side source) using the JVM's classpath. Make sure to add your source directories first in your classpath when running the development shell.

The Development Shell is the launching point for a hosted mode browsing session. This browser displays your application and gives you the standard controls of a web browser, plus a Compile/Browse Button to deploy the client-side code to JavaScript for viewing with a standard web browser.

Debugging messages are displayed within the Development shell window. Some of these messages are from the GWT toolkit, others can be generated using calls to GWT.log(). For example, modifying the standard project to emit a debug message inside the ClickListener results in a debug message displaying on the Development Shell window whenever the user clicks the button.

   import com.google.gwt.core.client.GWT;

   ...

   button.addClickListener(new ClickListener() {
      public void onClick(Widget sender) {
        GWT.log("User Pressed a button.", null); // Added debugging message
        if (label.getText().equals(""))
          label.setText("Hello World!");
        else
          label.setText("");
      }

Calls to GWT.log() are intended just for use while debugging your application. They are optimized out in web mode. For example, consider the following change to the onClick() method intended to intentionally trigger an exception:

  public void onClick(Widget sender) {
        GWT.log("User Pressed a button.", null);
        Object nullObject = null;
        nullObject.toString(); // Should cause NullPointerException

When the hosted application encounters an exception, a message is printed on the Development Shell window. The Development Shell highlights the exception with a red icon. In this example, when you click on the button in the browser window, a NullPointerException is triggered and the back trace for the exception displays in the status area below the log area. Clicking on the exception message or icon displays the full text of the exception in the message area below.

The Development Shell window can display more verbose debugging by specifying the -logLevel command line argument. Specifying the level of SPAM turns on many messages inside of the GWT engine. These messages are displayed in a hierarchical tree which can be manipulated by clicking on individual lines or by using the Expand All and Collapse All icons in the toolbar.

See the <module>-shell script page for a full list of command line parameters.