I’ve spent the past week juggling with GWT, Maven 2, Eclipse, Jetty 6 and Tomcat 6. My goal was:
- Run GWT hosted mode using noserver switch in order to use my own application server / container. The reason for this was that I wanted to experiment with Jetty 6’s continuations and Tomcat 6’s Cometprocessor servlet interface
- Keep full debugging support for both server and client code in Eclipse in noserver mode
- Fully automated command line builds, packing and deployments using Maven
Switching to noserver hosted mode in GWT has a couple of implications. When using the -noserver flag, your external server is used by the GWT Hosted Mode browser to serve up both your dynamic content, and all static content (such as the GWT application’s host page, other HTML files, images, CSS, and so on.). GWT’s internal Tomcat is no longer used. This also means that you are totally on your own with everything happening on the server side.
First task was ensuring full server side debugging support with Jetty as servlet container. Although I should be technically possible (somehow) to get this to work using WTP, I opted against this and instead went for the Jetty Launcher eclipse plugin. As it turned out, this plugin hasn’t be updated in ages and did not support Jetty 6 (only version 6 and higher of Jetty supports continuations). After digging trough the forums I’ve discovered a patch for the Jetty Launcher that provided Jetty 6 compatibility. Building a custom version of the plugin proved difficult because I did not have any previous experience with compiling eclipse plugins and the instructions by the author of the patch were kind of vague. In the end I figured it out and the plugin was working flawless. (Feel free to email me for the binaries if you would like to avoid going through the same).
The situation with Tomcat was very similar. I choose the Sysdeo Tomcat Launcher plugin enabled it for my project and .. ran into the next problem. Unlike Jetty, Tomcat does not load any classes from the environment classpath. Which posed a problem because I rather wanted to avoid storing my project dependencies at another location than the local maven repository which was not a problem for Jetty since the Jetty Launcher simply passed the local maven repository folder as a classpath entry to jetty which in turn happily loaded everything directly from the repository. For tomcat there was no solution but utilize the maven-dependency-plugin to populate <hosted_webappfolder>/WEB-INF/lib during the packaging phase with the maven project dependencies from the maven repos.
Now that the problems are solved, I am able to develop and debug in noserver mode at least just as comfortable as before without the –noserver switch but at the advantage of being in total control of the servlet container and being able to use the latest server features as well.