For the past eight(8) years Schalk Neethling has been working as a freelance developer under the pseudo of Volume4 and is now the president of Overt Strategy Consulting. During this period he has completed over 300 projects ranging from full web application development to complete branding. As president and lead developer of Overt Strategy Consulting, Schalk Neethling and his team has released a 100% Java standards based content management system called AlliedBridge and business document exchange and review system, called Doc-Central. Schalk Neethling is also actively involved on a daily basis in the open source, web standards and accessibility areas and is a current active member of the Web Standards Group. Schalk is also the co-founder and president of the non-profit The South Web Standards and Accessibility Group, which aims to actively educate and raise awareness of web standards and accessibility to both the developer society as well as business large and small. Schalk also has a long relationship with DZone and is currently zone leader for both the web builder, css.dzone.com, as well as the .NET zone, dotnet.dzone.com, and you can find a lot of his writing there as well as on his blog located at schalkneethling.alliedbridge.com. Schalk is constantly expanding on his knowledge of various aspects of technology and loves to stay in touch with the latest happenings. For Schalk web development and the internet is not just a job, it is a love, a passion and a life style. Schalk has posted 173 posts at DZone. View Full User Profile

Working With The GWT Shell

06.09.2008
| 25401 views |
  • submit to reddit

The GWT shell is one of the most important components GWT provides, and one you’ll use every day when developing GWT applications.The shell is composed of three main parts: a logging console, an embedded Tomcat server, and the hosted mode browser. The GWT shell console provides an enhanced logging interface and centralized GUI as a GWT dashboard. The hosted mode browser is capable of invoking your Java classes directly on browser events, rather than requiring a compilation to JavaScript; thus you can use a standard Java debugger to work with your Ajax code, instead of relying solely on compiled JavaScript for testing and interaction. The development server, Tomcat Lite, facilitates local development and testing of server-based resources.

GWTShell supports several common command-line parameters you should be familiar with. The parameters are described in table 1:

GWTShell [-port port-number] [-noserver] [-whitelist whitelist-string]
[-blacklist blacklist-string] [-logLevel level] [-gen dir] [-out dir]
[-style style] [url]

Table 1 GWTShell parameters

Parameter Description
-port Runs an embedded Tomcat instance on the specified port (defaults to 8888)
-noserver Prevents the embedded Tomcat server from running, even if a port is specified
-whitelist Allows the user to browse URLs that match the specified regular expressions (comma or space separated)
-blacklist Prevents the user from browsing URLs that match the specified regular expressions (comma or space separated)
-logLevel The logging level: ERROR, WARN, INFO, TRACE, DEBUG, SPAM, or ALL
-gen The directory into which generated files will be written for review
-out The directory to which output files will be written (defaults to current)
-style Script output style: OBF[uscated], PRETTY, or DETAILED (defaults to OBF)
url Launches the specified URL automatically

The first of these parameters that you may want to tweak is -logLevel, which changes the output level of the logging console. This is the first thing you notice when the GWT shell starts up.

The logging console

The GWT shell console is a hierarchical logging display with a few simple buttons that invoke the hosted mode browser and control logging output. The logging display is controlled by the -logLevel option on the GWTShell command line. Valid log levels are shown in table 2; the default level is INFO.

Table 2 GWTShell -logLevel options

Log Level Description
ERROR Shows only critical errors in the GWT shell code.
WARN Shows uncaught exceptions in user code. WARN and ERROR information are displayed in red in the shell window.
INFO (Default.) Shows server startup information and invocations into specific GWT modules. Most of the time, what you’ll see in this mode is simply "Starting HTTP on port 8888."
TRACE Shows each request logged, as well as module instantiations, their locations on the class path, and the time. This is perhaps the most useful mode for day-to-day development. TRACE and INFO level information are displayed in gray in the shell window.
DEBUG Shows the binding of classes inside the GWT shell for code invocations and URL mapping. This mode is also useful for debugging compilation errors into JavaScript, should you encounter them. DEBUG level information is displayed in green in the shell window.
SPAM Shows all ClassLoader events and invocations to native JavaScript. SPAM level information is displayed in teal in the shell window.
ALL Shows all logging information.

The GWT shell logging console shows different log level messages in different colors.The GWT shell logging console shows different log level messages in different colors.

From the GWT shell console GUI, you also have the option to invoke the hosted mode browser. The hosted mode browser is what allows you to explore your Java application using a browser and browser-based events.

The hosted mode browser

The hosted mode browser operates as a test browser harness that directly invokes Java binary code in response to browser events. This allows you to skip the step of compiling to JavaScript and to immediately see changes to your code, as well as to perform step-through debugging of code between the client and server sides.

he hosted mode browser also provides a shortcut to executing the compiled JavaScript version of your application; this is known as web mode. While you’re using the hosted browser from GWT, you can click the Compile/Browse button to perform a complete compilation of your Java to JavaScript and then browse your hosted application in the shell’s development web server.

Note that it’s important to make sure you have the GWT_EXTERNAL_BROWSER environment variable set before you click Compile/Browse. For example, on Linux you would set it like this:

export GWT_EXTERNAL_BROWSER=/usr/bin/firefox

This defines the command line that the GWT shell will invoke to launch a browser against the hosted Tomcat.

ou can also use the hosted mode browser apart from the GWT shell’s Tomcat instance with the -noserver option. This tells the shell not to use the embedded Tomcat instance in hosted mode, but rather to use an external server that you specify. Using an external web server, or Java container, can have several advantages. You can, for example, use the standalone browser to debug and test Java UI code that is talking to PHP or .NET backends that can’t otherwise be run in the GWT shell. Or you can use a Java backend that may run in a different container than Tomcat.

Regardless of which container you use, it’s recommended that for hosted mode use you name your context path name the same as your module: for example, com.manning.gwtip.helloserver.HelloServer. Doing this will make it easier to map your service servlet calls later.

This article is excerpted from Chapter 1 of GWT in Practice, by Robert Cooper and Charlie Collins, and published in May 2008 by Manning Publications.
Published at DZone with permission of its author, Schalk Neethling.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)