In development mode, this wasn't an issue because there is two easy workarounds. I started out by using the -server option and build a customer ServletContainerLauncher which allowed my to start the whole application (jetty server and all) within the dev-mode. This solution worked fine and even supported the "restart/reload" option with eclipse but after working with GWT for a while, I realized this was an overkill. Instead, I realize that you can use the -no-server option to achieve the same thing. So instead of trying to force our application to run the GWT container, I started up our application and the GWT engine in dev mode. GWT engine then generated the javascript and dumped it in our applications webapp directory. When the browser hit our web server it would then serve up the html and js files that GWT generated but because the ?gwt.codesrv= argument existed on the URI, the GWT browser plugin would then communicate to the GWT engine. Of course, in this mode the reload/restart button didn't work in eclipse but one advantage of this solution is you can easily swap between production and dev mode.
Unfortunately, getting JUnit tests running was not as easy. So in order to get junit tests running within our own servlet container, I was forced to patch the JUnitShell class. The patch does the following:
- Add a -server option to the enable a custom ServletContainerLauncher
- Created a CustomerLauncher that subclasses the ServletContainerLauncher. This allowed for the JunitTest to resolve the Jetty container and map the servlets from the my GWT module into the junit modules that was generated. See line 148
The patch is attached to the following google ticket.
No comments:
Post a Comment