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,, as well as the .NET zone,, and you can find a lot of his writing there as well as on his blog located at 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

GWT: Using An External Development Server

  • submit to reddit

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

File Purpose
ModuleName.html Host page
ModuleName.nocache.html GWT nocache initialization script
gwt.js Core GWT JavaScript (not application specific)
hosted.html Core hosted mode JavaScript (not application specific)

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



APPDIR=`dirname $0`;
java -XstartOnFirstThread \
-cp $CPGWT \
-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.

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.)