Announcing GWT 1.6 Milestone 1

[Scott Blum]

Greetings GWT developers,

The GWT team is happy to announce the availability of 1.6 Milestone 1! Binary distributions are available for download directly from GWT's Google Code project.

http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0

As always, milestone builds like this are use-at-your-own-risk. There are known bugs, and it definitely isn't ready for production use. Please expect some trial and error getting everything to work. The javadoc that comes bundled with the distribution should be up-to-date, but the online Developer Guide (http://code.google.com/docreader/#p=google-web-toolkit-doc-1-6) is still very much a work in progress. We will be updating it over the next several weeks. In lieu of an up-to-date Developer Guide and release notes, below are the major highlights relative to GWT 1.5.3.

*** New Project Structure in GWT 1.6 ***

One of the biggest changes to GWT 1.6 is a new project structure. The old output format has been replaced by the standard Java web app expanded "war" format, and the actual directory name does default to "/war". Note that the war directory is not only for compiler output; it is also intended to contain handwritten static resources that you want to be included in your webapp alongside GWT modules (that is, things you'd want to version control). Please also note that the "GWTShell" and "GWTCompiler" tools will maintain their legacy behavior, but they have been deprecated in favor of new "HostedMode" and "Compiler" tools which use the new war output. When 1.6 is officially released, we will be encouraging existing projects to update to the new directory format and to use the new tools to take advantage of new features and for compatibility with future GWT releases.

The sample projects provided in the GWT distribution provide an example of correct new project configurations. For more details on the specifics of the new project format, please see GWT 1.6 WAR design document (http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6).

A couple of important changes we should highlight here:

- Projects with server-side code (GWT RPC) must configure a "web.xml" file at "/war/WEB-INF/web.xml". This web.xml file must define and publish any servlets associated with the web application. See the included DynaTable sample. Additionally, server-side library dependencies must be copied into "/war/WEB-INF/lib". For example, any GWT RPC servlets must have a copy of gwt-servlet.jar in this folder.

- HTML host pages will no longer typically be located in a GWT module's public path. Instead, we'll be recommending that people take advantage of the natural web app behavior for serving static files by placing host pages anywhere in the war structure that makes sense. For exmaple, you might want to load a GWT module from a JSP page located in the root of your web app. To keep such handwritten static files separate from those produced by the GWT compiler, the latter will be placed into module-specific subdirectories. Any page that wishes to include a GWT module can do so via a script tag by referencing the GWT-produced "<module>.nocache.js script" within that module's subdirectory. As of 1.6, we'll be recommending that only module-specific resources used directly by GWT code, such as image files needed by widgets, should remain on the public path. See the included Showcase sample for some examples of this distinction.

- When you do need to load resources from a module's public path, always construct an absolute URL by prepending GWT.getModuleBaseURL(). For example, 'GWT.getModuleBaseURL() + "dir/file.ext"'. This advice has not changed, but in the past it was easy to be sloppy with this, because the host page and GWT module typically lived in the same directory, so using a relative URL would usually do the right thing. Now that GWT modules live in a subdirectory, you must reference public resources through GWT.getModuleBaseURL().

*** Hosted Mode Enhancements ***

Although the legacy GWTShell still uses an embedded Tomcat server, the new HostedMode runs Jetty instead. There is also a new "Restart Server" button on the main hosted mode window. Clicking this button restarts the internal Jetty server, which allows Java code changes to take effect on the server without having to completely exit and restart hosted mode. This is useful when making code changes to RPC servlets, or when serializable RPC types are modified and the server and client are out of sync.

*** New EventHandler System ***

Event handlers have been added to replace the old event listeners used by Widgets, History, and various other classes. The new system has a few differences from the old system:

- EventHandler methods always take a single parameter: the GwtEvent that the Widget fired. For example, ClickHandler has a single method onClick(ClickEvent).

- Each GwtEvent contains accessors relevant to the event, such as the key that was pressed on KeyEvents. Native events provide access to the underlying native event object.

- Each EventHandler defines only one method, so you do not need to create empty methods just to satisfy the interface requirements.

For users who create their own Widgets, you no longer need to manage listeners manually. Every Widget has a HandlerManager that manages all of its handlers. For native events, such as ClickEvent, just call addDomHandler() from within your code to register a handler and sink the associated event on the Widget. When the native event is detected, the handler will automatically be called. For logical events, such as SelectionEvent, call addHandler() and fire the event manually using the fireEvent() method.

You can see examples of EventHandler usage in many of the updated GWT widgets and samples, or in new projects created with the new webAppCreator tool.

You can now trigger a native event on almost any Element. Create a new native event using the Document.create*Event() methods, then dispatch it on a specific Element by calling Element.dispatchEvent(). These methods allow you to expand your test coverage in ways that were previously impossible.

*** New Widgets ***

DatePicker

The new DatePicker and DateBox widgets allow your users to select a date from a calendar. The Showcase sample provides examples of both of these widgets.

LazyPanel

The new LazyPanel widget allows you to delay the creation of certain sections of your application until they are first accessed, improving startup performance. For example, if your application has a seldom used "Help" section, you can wrap it in a LazyPanel and create the user interface only if and when the user tries to access it. To use the LazyPanel, extend the class and override the abstract createWidget() method. The createWidget() method will be called the first time you call setVisible() on the LazyPanel.

*** Fixed Issues ***

Please see our bug tracker for a full list of fixed issues and enhancements (http://code.google.com/p/google-web-toolkit/issues/list?can=1&q=status:Fixed,FixedNotReleased%20milestone:1_6_RC&num=1000).

As always, please report bugs to our issue tracker (http://code.google.com/p/google-web-toolkit/issues/list) after doing a quick search to see if your issue has already been reported.

Happy coding,

Scott, on behalf of the GWT team

[Ray Cromwell]

Congratulations on the milestone release! I think some beers are in order. :)

-Ray

[nicolas de loof]

I just notice the "About" class has not the GWT_VERIOSN_NUMBER set.

Seems the code expects some String replacement for @GWT_VERSION@.

I'm using About.GWT_VERSION_NUM constant in gwt-maven-plugin to detect the GWT version used when user provides it's own implementation.

Cheers,

Nicolas

[stuckagain]

Hi,

As a confidence test I tried to compile our projects with the new
release and failed miserably.

Is it expected that the GWT JavaScript compiler now seems to use
native code ? Is this to support compiling in multiple processes ? Or
is it a sideeffect of some other changes ?

I normally build our final release builds on SunOS and we use the
windows dev jar.

Why do I do this ? Corperate BS forces me to access all sources on a
clearcase filessystem (running on top of NFS) which is extremely
slow.
When I build on SunOS I can do it on the actual viewserver. I guess I
have another reason to request snapshot views (which puts everything
on a local disc instead) :-)

David


[echo] Invoking GWT JavaScript compiler.
[java] WARNING: 'com.google.gwt.dev.GWTCompiler' is deprecated
and will be removed in a future release.
[java] Use 'com.google.gwt.dev.Compiler' instead.
[java] Unable to load required native library 'gwt-ll'. Detailed
error:
[java] Can't load library: /scm/vobs/rlsCOTS5/gwt/JAVA/lib/libgwt-
ll.so)

[java] Your GWT installation may be corrupt
[java] Compiling module com.swift.sawa.admin.Admin
[java] Removing units with errors
[java] [ERROR] Errors in 'jar:file:/scm/vobs/rlsCOTS5/
gwtincubator/JAVA/lib/gwt-incubator.jar!/com/google/gwt/user/client/ui/
SuggestionMenuImpl.java'
[java] [ERROR] Line 142: The method itemOver(MenuItem,
boolean) in the type MenuBar is not applicable for the arguments
(MenuItem)
[java] [ERROR] Line 179: The method itemOver(MenuItem)
of type SuggestionMenuImpl must override or implement a supertype
method
[java] [ERROR] Line 188: The method itemOver(MenuItem,
boolean) in the type MenuBar is not applicable for the arguments
(SuggestionMenuImpl.SuggestionItem)
[java] Removing invalidated units
[java] [WARN] Compilation unit 'jar:file:/scm/vobs/rlsCOTS5/
gwtincubator/JAVA/lib/gwt-incubator.jar!/com/google/gwt/widgetideas/
client/SuggestBoxOverride.java' is removed due to invalid reference
(s):
[java] [WARN] jar:file:/scm/vobs/rlsCOTS5/gwtincubator/
JAVA/lib/gwt-incubator.jar!/com/google/gwt/user/client/ui/
SuggestionMenuImpl.java
[java] [ERROR] Errors in jar:file:/scm/vobs/rlsCOTS5/
gwtincubator/JAVA/lib/gwt-incubator.jar!/com/google/gwt/widgetideas/
client/DropDownPanel.java
[java] [ERROR] Line 391: Unresolvable native reference to
field 'popupListeners' in type
'com.google.gwt.user.client.ui.PopupPanel'
[java] [ERROR] Cannot proceed due to previous errors

> (http://code.google.com/p/google-web-toolkit/issues/list?can=1&q=statu...
> ).

[Arthur Kalmenson]

Congratulations! I'll try to give this a swing this week or next week,
I hope it doesn't break the gwt-maven plugin too badly. Does anyone
know when this milestone will hit the central Maven repo?

--
Arthur Kalmenson

[Scott Blum]

Hi stuckagain,

It looks like you are using a version of the incubator jar that is not compatible with the milestone build.  Can you start a new thread about that and CC e...@google.com?

I'm not sure why the compiler is trying to load gwt-ll, I will check it out, thanks.

Scott

[Emily Crutcher]

Only the current gwt-incubator trunk is validated to work against the release jar. We'll be releasing a new gwt-incubator jar soon, but I'm still working on getting all the demos to build and display correctly.

--
"There are only 10 types of people in the world: Those who understand binary, and those who don't"

[Scott Blum]

By the way, I should point out that Maven integration might be easier in the future.

http://code.google.com/p/google-web-toolkit/issues/detail?id=1032

[Scott Blum]

Nicolas, I can't reproduce the issue you're seeing.  Do you have a weird classloader setup?  Or is it possible the code you have that references About needs to be recompiled?  Try the following test.. create a Main.java in your GWT install directory and run the following commands.

Main.java:

import com.google.gwt.dev.About;

public class Main {

  public static void main(String[] args) {

    System.out.println(About.GWT_NAME);

    System.out.println(About.GWT_SVNREV);

    System.out.println(About.GWT_VERSION);

    System.out.println(About.GWT_VERSION_NUM);

  }

}

Command line:

C:\gwt-windows-1.6.0>"%JAVA_HOME%\bin\javac.exe" -cp gwt-dev-windows.jar Main.java

C:\gwt-windows-1.6.0>"%JAVA_HOME%\bin\java.exe" -cp .;gwt-dev-windows.jar Main

Google Web Toolkit

1.6@4621M

Google Web Toolkit 1.6.0

1.6.0

C:\sandbox\gwt-windows-1.6.0>

This seems correct to me.

[nicolas de loof]

Your example works,

The issue is that I don't load the class from a classloader, I'm using BCEL to read the .class and access the GWT_VERSION_NUM field, so static initializer is not executed.

I now fallback to reading the About.properties if present, this fix my version-detection issue

Cheers,

Nicolas

[Scott Blum]

LOL, well that would explain it. :)  To be fair, in previous versions this would have worked since those fields were (I think wrongly) compile-time-constants.

[Matthew Mastracci]

Scott et. al,

Great release!  I spent a few hours migrating our codebase and build process without much trouble.  

1.  The new expanded WAR format makes life a lot easier for us to run with -noserver.  With 1.5, we had to regenerate the hosted.html and nocache.js files every time something changed.  Now we're just pointing Tomcat at war/ and letting tomcat serve them directly.

2.  The compiler task crashes Java 1.6 on Mac now.  The previous versions would run fine with the 64-bit JVM (even though SWT isn't compatible).  Would it be possible to lazy load SWT so that we can take advantage of the faster 1.6 JVM on OSX?

     [java] Invalid memory access of location 00000000 rip=01160767

3.  Our final output codesize grew by ~2-3% (compressed size).  Scanning the symbol files seems to point towards a bunch of new event handling classes that showed up.  I haven't ported all of our widgets over to using handlers instead of listeners, so it's likely a result of some code duplication as well.

4.  None of our custom linkers required major work to bring it up to date, with the exception of some tweaks to add a third parameter to window.external.gwtOnload().

5.  One cool thing that was missing from the release notes is new the ability to specify multiple modules for the compile task.  Based on some wallclock testing, specifying multiple modules shaves off ~30 seconds off compile time of any modules on top of the first:

Individual times:

     [java]    Compilation succeeded -- 51.814s

     [java]    Compilation succeeded -- 170.986s

     [java]    Compilation succeeded -- 91.488s

All together:

     [java]    Compilation succeeded -- 55.121s

     [java]       Compilation succeeded -- 141.052s

     [java]          Compilation succeeded -- 55.492s

Note that each module's log messages are indented one level further, indicating the extra speed boost.  ;)

Overall, an awesome release.  Thanks, all.

Matt.

[Scott Blum]

On Fri, Feb 6, 2009 at 12:30 PM, Matthew Mastracci <mat...@mastracci.com> wrote:

2.  The compiler task crashes Java 1.6 on Mac now.  The previous versions would run fine with the 64-bit JVM (even though SWT isn't compatible).  Would it be possible to lazy load SWT so that we can take advantage of the faster 1.6 JVM on OSX?

     [java] Invalid memory access of location 00000000 rip=01160767

Good point, I can take a look at this.  The compiler should be able to run without loading SWT.

5.  One cool thing that was missing from the release notes is new the ability to specify multiple modules for the compile task.  Based on some wallclock testing, specifying multiple modules shaves off ~30 seconds off compile time of any modules on top of the first:

Individual times:

     [java]    Compilation succeeded -- 51.814s

     [java]    Compilation succeeded -- 170.986s

     [java]    Compilation succeeded -- 91.488s

All together:

     [java]    Compilation succeeded -- 55.121s

     [java]       Compilation succeeded -- 141.052s

     [java]          Compilation succeeded -- 55.492s

Note that each module's log messages are indented one level further, indicating the extra speed boost.  ;)

LOL!  I had no idea this actually made any difference in speed, so I guess it's a bonus easter egg feature. :P

Scott

 

[Jeff J.]

I'm getting class not found exceptions when trying to launch my
project in hosted mode using this build, saying Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found. I tried to
create a fresh new project using webAppCreator and I get
NoClassDefFoundError looking for com/google/gwt/user/client/rpc/
RemoteService. I'm using jdk1.6.0_11 32bit JVM on windowsXP 64bit. Any
suggestions on what I could be doing wrong? For now I am needing to
use r4603 from the trunk with the modified jetty jar in the gwt tools
to use hosted mode.

Thanks,
Jeff

On Feb 6, 3:22 pm, Scott Blum <sco...@google.com> wrote:

[Scott Blum]

Not sure what might be causing the SAX problem.  Can you file an issue with more detailed information?

The NoClassDefFound is caused by not copying gwt-servlet.jar into WEB-INF/lib.  If you run the ant build file, it will do this automatically, but we have a fix in place for the next milestone that makes webAppCreator go ahead and do this for you for the case where you're just loading the project up in Eclipse without ever running the build file.

This particular error state is now detailed here in the "common pitfalls" section:

http://code.google.com/docreader/#p=google-web-toolkit-doc-1-6&s=google-web-toolkit-doc-1-6&t=DevGuideImplementingServices

[Jeff J.]

Scott,

Your mentioned solution of copying gwt-servlet.jar into WEB-INF/lib
did work for the webAppCreator project, however my existing large
project still has the ClassNotFoundException for
org.apache.xerces.jaxp.SAXParserFactoryImpl. I am still at a loss of
ideas, as gwt-user.jar, gwt-dev-windows.jar, and gwt-servlet.jar are
the same with both projects. Could it be possible another server-side
lib is causing a conflict? The complete stack trace is below:

2009-02-15 23:01:30.086::WARN: failed
com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload@c8ba50{/,E:\project_src\ProjGWT\war}
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance
(SAXParserFactory.java:134)
at org.mortbay.xml.XmlParser.setValidating(XmlParser.java:92)
at org.mortbay.xml.XmlParser.<init>(XmlParser.java:84)
at org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp
(TagLibConfiguration.java:199)
at org.mortbay.jetty.webapp.WebAppContext.startContext
(WebAppContext.java:1217)
at org.mortbay.jetty.handler.ContextHandler.doStart
(ContextHandler.java:513)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
448)
at com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload.doStart(JettyLauncher.java:236)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart
(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start
(JettyLauncher.java:283)
at com.google.gwt.dev.HostedMode.doStartUpServer(HostedMode.java:368)
at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:587)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:394)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:231)
2009-02-15 23:01:30.086::WARN: Nested in
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found:
java.lang.ClassNotFoundException
at com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload$1.findClass(JettyLauncher.java:217)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass
(WebAppClassLoader.java:375)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass
(WebAppClassLoader.java:337)
at javax.xml.parsers.FactoryFinder.getProviderClass
(FactoryFinder.java:111)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:
146)
at javax.xml.parsers.FactoryFinder.findJarServiceProvider
(FactoryFinder.java:298)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223)
at javax.xml.parsers.SAXParserFactory.newInstance
(SAXParserFactory.java:128)
at org.mortbay.xml.XmlParser.setValidating(XmlParser.java:92)
at org.mortbay.xml.XmlParser.<init>(XmlParser.java:84)
at org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp
(TagLibConfiguration.java:199)
at org.mortbay.jetty.webapp.WebAppContext.startContext
(WebAppContext.java:1217)
at org.mortbay.jetty.handler.ContextHandler.doStart
(ContextHandler.java:513)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
448)
at com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload.doStart(JettyLauncher.java:236)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart
(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start
(JettyLauncher.java:283)
at com.google.gwt.dev.HostedMode.doStartUpServer(HostedMode.java:368)
at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:587)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:394)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:231)
2009-02-15 23:01:30.086::WARN: Error starting handlers
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance
(SAXParserFactory.java:134)
at org.mortbay.xml.XmlParser.setValidating(XmlParser.java:92)
at org.mortbay.xml.XmlParser.<init>(XmlParser.java:84)
at org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp
(TagLibConfiguration.java:199)
at org.mortbay.jetty.webapp.WebAppContext.startContext
(WebAppContext.java:1217)
at org.mortbay.jetty.handler.ContextHandler.doStart
(ContextHandler.java:513)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
448)
at com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload.doStart(JettyLauncher.java:236)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart
(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start
(JettyLauncher.java:283)
at com.google.gwt.dev.HostedMode.doStartUpServer(HostedMode.java:368)
at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:587)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:394)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:231)
2009-02-15 23:01:30.086::WARN: Nested in
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found:
java.lang.ClassNotFoundException
at com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload$1.findClass(JettyLauncher.java:217)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass
(WebAppClassLoader.java:375)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass
(WebAppClassLoader.java:337)
at javax.xml.parsers.FactoryFinder.getProviderClass
(FactoryFinder.java:111)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:
146)
at javax.xml.parsers.FactoryFinder.findJarServiceProvider
(FactoryFinder.java:298)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223)
at javax.xml.parsers.SAXParserFactory.newInstance
(SAXParserFactory.java:128)
at org.mortbay.xml.XmlParser.setValidating(XmlParser.java:92)
at org.mortbay.xml.XmlParser.<init>(XmlParser.java:84)
at org.mortbay.jetty.webapp.TagLibConfiguration.configureWebApp
(TagLibConfiguration.java:199)
at org.mortbay.jetty.webapp.WebAppContext.startContext
(WebAppContext.java:1217)
at org.mortbay.jetty.handler.ContextHandler.doStart
(ContextHandler.java:513)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:
448)
at com.google.gwt.dev.shell.jetty.JettyLauncher
$WebAppContextWithReload.doStart(JettyLauncher.java:236)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart
(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:39)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start
(JettyLauncher.java:283)
at com.google.gwt.dev.HostedMode.doStartUpServer(HostedMode.java:368)
at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:587)
at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:394)
at com.google.gwt.dev.HostedMode.main(HostedMode.java:231)

On Feb 13, 2:18 pm, Scott Blum <sco...@google.com> wrote:
> Not sure what might be causing the SAX problem.  Can you file an issue with
> more detailed information?
> The NoClassDefFound is caused by not copying gwt-servlet.jar into
> WEB-INF/lib.  If you run the ant build file, it will do this automatically,
> but we have a fix in place for the next milestone that makes webAppCreator
> go ahead and do this for you for the case where you're just loading the
> project up in Eclipse without ever running the build file.
>
> This particular error state is now detailed here in the "common pitfalls"

> section:http://code.google.com/docreader/#p=google-web-toolkit-doc-1-6&s=goog...

[Jeff J.]

Update: I've fixed the issue by simply including xercesImpl.jar from
GWT Tools in WEB-INF/lib. Still not exactly sure why it is needed now
and not previously, but it is working right now in hosted mode so all
is good.

Thanks,
Jeff

> ...
>
> read more »

[Scott Blum]

Jeff: previously everything we shipped in gwt-dev-*.jar was accessible to server code.  With the new entry point, we isolate the web application so that you'll be explicit about your dependencies.. this make it much more likely that when you deploy your GWT app to a real server, things just work and you won't have to debug configuration errors.