To be honest, we kind of punted on a full JUnitShell port for a couple of reasons: 1) Backwards compatibility. If we updated JUnitShell to use HostedMode, it seems like old test cases would probably break. The idea of a JUnitHostedMode is a good one... but how would we be able to tell which one the user meant, since the JUnit framework is in control?
2) It should work okay for pure client-side testing. I take it from your message that you're doing something more sophisticated, that involves server-side code also? On Thu, Feb 19, 2009 at 4:15 AM, Netsurfer <[email protected]> wrote: > > Hi, > I was using GWT 1.5 since some weeks ago, now I moved my application > to GWT1.6M1 in order to use the new war structure with a Spring server > application context. > Everything works fine with HostedMode: this version simplifies a lot > web frameworks integration. > > Now the problem: > I want to test my application with GwtTestCase but it uses JUnitShell > that extends GwtShell and there isn't any implementation like a > JUnitHostedMode that use the new war structure or, more in general, > the possibility to use HostedMode instead of GwtShell in a > GwtTestCase. > The consequence is that I'm not able to test my GWT Spring application > because every file inside the new war structure isn't reachable on a > GwtShell and the Spring context isn't loaded. > > Is there any solution? > > Thanks in advanced, > Marco > > On 6 Feb, 16:26, Scott Blum <[email protected]> wrote: > > 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=statu. > .. > > ). > > > > 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. If you run into a > > serious issue, feel free to also reply back to this thread. > > > > Happy coding, > > Scott, on behalf of the GWT team > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
