On Monday, July 2, 2018 at 2:21:21 PM UTC+2, Leto wrote:
Hello Thomas,you answer is much appreciated, thank you!
Am Sonntag, 1. Juli 2018 21:32:56 UTC+2 schrieb Thomas Broyer:In the logs, do you see an entry with "Server […] could not be found in the web app, but was found on the system classpath" and then "Adding classpath entry '[…]gwt-dev.jar' to the web app classpath for this session" ?unfortunately, I don't see any of that line. I set the log level to "TRACE" for "com.google.gwt.dev.DevMode" via
<arg value="TRACE" />but the only line containing the word "classpath" is
Just to clarify: by "in the logs", I specifically meant the "Jetty" tab in the DevMode window.
That would in general mean that you're missing a JAR in your WEB-INF/lib for the given class or resource. But there can be false positives unfortunately, and no way to change GWT's behavior (which has always been that way, but in the mean time we updated Jetty which changed quite a few things here).Ok I understand. Until now, and still, I think the reason for the exception is, that there is more than one implementation of "org.eclipse.jetty.apache.jsp.JuliLog", or the wrong implementation for "org.apache.juli.logging.Log", I'm not exactly sure how to interpret the exception.
Given what you shared about your classpath and WEB-INF/lib (where both classes only exist in gwt-dev.jar), I'm ready to bet that this is a classloader issue, where at one point the gwt-dev.jar is added to the webapp classloader (almost as if it was in the WEB-INF/lib), and then there are "conflicts" between the same class from the system classloader (DevMode) and the webapp classloader (WEB-INF/lib) can't be cast from/to one another.
The recommended setup with GWT 2.7+ is to run your webapp out of a "standard" server (Jetty, Tomcat, etc.), as an "exploded WAR", and running Super Dev Mode (CodeServer with -launchDir, or DevMode with -noserver) separately, pointing to the same directory that the server serves as the webapp (or configuring the server to also look into an additional directory for web resources, so it can find and serve the *.nocache.js generated by the Super Dev Mode)Ok - so, is my understanding correct, that when I have a separate webserver, like Jetty (e.g. via Eclipse Jetty plugin) or Tomcat, and I start my WebApp with it (via an exploded WAR) and I also start DevMode without the embedded server OR the CodeServer, those two (the separate webserver and the CodeServer) do communicate with the help of the "myapp.nocache.js" file?What I do not understand is, there is also the bookmarklet "Dev Mode On/Off", how does that work / what is it doing, or is that bookmarklet of no use with the aforementioned setup?
When you start the CodeServer with -launcherDir, it writes a special myapp.nocache.js that automatically calls the CodeServer to (re)compile the application and then load the compiled app.
When it starts, the CodeServer starts a server (HTTP, port 9876 by default) and writes the a myapp/myapp.nocache.js in the -launcherDir, that references the CodeServer's URL (when you launch the DevMode, it actually launches the CodeServer behind the scene, with the -launcherDir being the same as the -war).
When your browser loads that myapp.nocache.js (through the web server that serves your webapp), it automatically "calls" the CodeServer to compile the app and then load it; this is what the bookmarklets did prior to GWT 2.7 (and can still do, if you don't use -launcherDir).
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment