Thanks Thomas. Can you also explain how things operate for GAE when and if I were to employ SuperDev mode - I thought there would be no impact as the GWT module is loaded by redirecting the HTML script to the compiler web server, but when I looked at this before I ran into some issues where the "ip address" serving the hosted page (in GAE) needed to match the compiler server (SuperDev Mode) and until I was using the same "localhost" it wouldn't work.
Do you know if much sociability testing between 2.6 and GAE is occurring? If I run into issues should I post them with GAE or GWT? Who would be best/fastest to address them? G On Thursday, 13 March 2014 12:25:56 UTC+10, Thomas Broyer wrote: > > It does not apply to GAE as they just hook into DevMode extension points > replacing the JettyLauncher with their own: > https://code.google.com/p/googleappengine/source/browse/trunk/java/src/main/com/google/appengine/tools/development/gwt/AppEngineLauncher.java > > On Thursday, March 13, 2014 3:18:43 AM UTC+1, gslender wrote: >> >> Does any of the changes in 2.6 in relation to the Jetty server and class >> loaders mentioned here impact users who are building GWT apps with the GAE >> dev server? I've yet to fully explore 2.6 with the current GAE releases, >> and haven't really followed the issue you've outlined here either, but >> wanted to know how internally the Google team members manage inter-op >> between GAE and GWT in this area (and to the same extent the Google Eclipse >> tools). >> >> Thanks >> Grant >> >> >> On Sunday, 9 March 2014 10:09:23 UTC+10, Thomas Broyer wrote: >>> >>> Hi all, >>> >>> The update from Jetty 6 to Jetty 8 wasn't without regressions. One of >>> them is a classloader issue. >>> >>> First, when starting DevMode, sometimes (IIRC, not for all projects, >>> might be because I tried with a WEB-INF/jetty-web.xml), it starts with: >>> >>> [WARN] Server resource 'org/eclipse/jetty/xml/configure_6_0.dtd' could >>> not be found in the web app, but was found on the system classpath >>> [WARN] Adding classpath entry >>> 'file:/home/tbr/.m2/repository/com/google/gwt/gwt-dev/2.6.0/gwt-dev-2.6.0.jar' >>> >>> to the web app classpath for this session >>> >>> Which is… bad! (it's gwt-dev.jar here!) >>> and is btw probably the cause of >>> https://code.google.com/p/google-web-toolkit/issues/detail?id=8526 (the >>> other known regression) >>> >>> Next, there are issues with javax.* APIs, such as JDO: >>> https://code.google.com/p/google-web-toolkit/issues/detail?id=8585 >>> This is because Jetty switched isSystemClass from "javax.servlet + >>> javax.xml" to "all of javax.": >>> >>> http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.11/org/mortbay/jetty/webapp/WebAppContext.java#95 >>> vs. >>> http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty.aggregate/jetty-all/8.1.12.v20130726/org/eclipse/jetty/webapp/WebAppContext.java#112 >>> >>> We already have issues with the way we do class loading in the webapp in >>> DevMode, e.g. >>> https://code.google.com/p/google-web-toolkit/issues/detail?id=4649 >>> >>> In the end, I wonder if we shouldn't just basically revert >>> https://code.google.com/p/google-web-toolkit/source/detail?r=4944, >>> except issuing a warning when we find the class in the system classpath >>> (but without automatically adding the JAR to the classpath and instead just >>> saying they should move it to WEB-INF/lib). Maybe we could add a switch (in >>> the form of a system property) to allow loading from the system classloader >>> (not restricted to Jetty system and server classes). >>> >>> What do you think? >>> >> -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
