GWTShell includes the -noserver command-line option, which instructs the toolkit not to start or use the embedded Tomcat instance. If you use -noserver, you're essentially telling GWT that you'll handle the server-side resources on your own, like a baseball player in the outfield calling a fly ball - "I got this one."
There are pros and cons to this approach. On the plus side, it is very flexible, allowing you to run any servlet container you want, with any configuration you need, all within hosted mode. On the downside, the configuration is up to you, and it makes sharing projects that involve RPC more difficult when the embedded Tomcat is not utilized. Overall, using -noserver is a great way to extend the server-side possibilities, as long as you're aware of the difficulties it can pose.
If you want to use -noserver, you'll need to configure an external server and context, and host a few files for your project there. To operate with the shell in hosted mode, you'll need to copy four files, at a minimum, from the compiled version of your GWT module into your external context. These files are listed in table 1.
Table 1 Required external container files for GWTShell -noserver usage
|ModuleName.nocache.html||GWT nocache initialization script|
With your external container and context in place, you then simply need to invoke GWTShell with the -noserver option and specify the correct port and path. This instructs the shell to point to the external server. Listing 1 shows a shell script for the Mac platform that demonstrates the use of these options.
Listing 1 Example Calculator-shell-noserver script for use with an external container
java -XstartOnFirstThread \
-cp $CPGWT com.google.gwt.dev.GWTShell \
-logLevel DEBUG -noserver -port 8080 "$@" \
When you start the shell in this manner, it will invoke the hosted mode browser and direct it to the specified path: http://localhost:8080/ENTRY_POINT/HOST_PAGE. If you wanted to, you could also not specify the port and path when you invoke the shell (simply start it with only -noserver), and then manually launch the hosted mode browser and type the correct URL in the address bar.
As the hosted mode browser connects to the HTML host page, it will look for a module bootstrap reference and execute the Java code it finds on its classpath. Be advised, though, that when using -noserver, server-side resources are completely out of the realm of GWT. This means server-side resources won't instantly update to changes like client-side resources do, and connecting a debugger, which can still be done, must be done outside the shell. Also remember that you have to set up server-side resources such as servlets, even for GWT RPC, on your own.
Although we think the -noserver switch can be helpful, we also feel that working with and understanding the embedded Tomcat instance is important. The reason not to abandon Tomcat Lite and always use other options is that once you're creating shared GWT projects that include server-side resources, you end up passing the configuration problem on. If you share GWT RPC resources, and they don't work in the stock toolkit, or in some automated fashion with the stock toolkit, the usability, acceptance, and adoption of your resources will likely plummet.
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.