After upgrading to GWT 2.8.2: Exception "ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype" during Super Dev Mode

[Leto]

Hello,

I recently had to upgrade a project from GWT 2.6.0 to GWT 2.8.2, while, at
the same time, the project migrated from Java 6 to Java 8, including a new
version of the IDE, namely Eclipse Oxygen.

For developing, we start the Super Dev Mode via an Ant script, which opens
the window where one can click on "Launch default browser" to open the GWT
app.

Unfortunately, upon opening the GWT app (clicking on the "Launch default
browser" button), I'm facing the following exception (shown in the console
and within the browser):


HTTP ERROR 500
Problem accessing /Login.jsp. Reason:


Server Error
Caused by:
javax.servlet.ServletException: java.util.ServiceConfigurationError: org.
apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not
a subtype
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:358)
at org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:
107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812
)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(
ServletHandler.java:1669)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.
doFilter(FilterChainProxy.java:316)
at org.springframework.security.web.access.intercept.
FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:126)
[...]
Caused by: java.util.ServiceConfigurationError: org.apache.juli.logging.Log:
Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239)
at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:
376)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.apache.juli.logging.LogFactory.<init>(LogFactory.java:78)
at org.apache.juli.logging.LogFactory.<clinit>(LogFactory.java:66)
at org.apache.jasper.runtime.TagHandlerPool.<clinit>(TagHandlerPool.java
:42)
at org.apache.jsp.Login_jsp._jspInit(Login_jsp.java:40)
at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(
JspServletWrapper.java:180)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:369)
[...]



Now, I found some posts about this problem:


-
https://stackoverflow.com/questions/43527854/upgrading-gwt-from-2-1-1-to-2-8-0-serviceconfigurationerror-org-apache-juli-lo
- https://github.com/tbroyer/gwt-maven-plugin/issues/65 ("GWT Eclipse
Plugin Running DevMode throws the famous jetty exception. #65")
- https://github.com/gwtproject/gwt/issues/9343 ("Jetty Exception
Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype #9343")


But neither of those were of help for me - maybe because I'm lacking some
experience with GWT and Java web apps in general.

The part of the Ant script to start the Super Dev Mode looks like this:

<target name="dev" depends="javac" description="Super Dev Mode">

<path id="gwtDevModeClasspath">
<pathelement location="src" />
<path>
<pathelement location="${classes}" />
<pathelement location="${env.GWT_HOME}/gwt-user.jar" />
<fileset dir="${env.GWT_HOME}" includes="gwt-dev*.jar"
/>
<fileset dir="${lib}">
<include name="gin-2.1.2.jar" />
<include name="guice-3.0.jar" />
<include name="javax.inject-1.jar" />
<include name="aopalliance-1.0.jar" />
<include name="guice-assistedinject-3.0.jar" />
<include name="gwt-visualization-1.1.2.jar" />
</fileset>
</path>
</path>


<java failonerror="true" fork="true" classname=
"com.google.gwt.dev.DevMode">
<classpath>
<path refid="gwtDevModeClasspath" />
</classpath>
<jvmarg value="-Xmx256m" />
<jvmarg value="-Xss8m" />
<jvmarg value="-Dgwt.codeserver.port=9876" />
<jvmarg value=
"-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"
/>
<jvmarg value=
"-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"
/>
<arg value="-startupUrl" />
<arg value="MyApp.html" />
<arg value="com.MyApp.MyApp" />
<arg value="-logLevel" />
<arg value="INFO" />
</java>

<echo>${toString:gwtDevModeClasspath}</echo>


</target>


After the dev mode GUI window has been closed, I print the used classpath
via <echo>, which is:

D:\[...]\gwt-2.8.2\gwt-user.jar
D:\[...]\gwt-2.8.2\gwt-dev.jar
D:\[...]\Eclipse\MyGwtApp\src
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\classes
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\aopalliance-1.0.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\gin-2.1.2.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\guice-3.0.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\guice-assistedinject-3.0.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\gwt-visualization-1.1.2.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\javax.inject-1.jar

There are quite a few libraries in the "WEB-INF/lib" directory, which the
GWT app needs:

aopalliance-1.0.jar
c3p0-0.9.2.1.jar
chart-2.2.1.jar
dom4j-1.6.1.jar
dozer-5.5.1.jar
gin-2.1.2.jar
gson-2.8.5.jar
guice-3.0.jar
guice-assistedinject-3.0.jar
gwt-servlet.jar
gwt-user-2.8.2.jar
gwt-visualization-1.1.2.jar
gwt-vl-2.0b-without-hibernate.jar
hamcrest-core-1.3.jar
hibernate-commons-annotations-4.0.2.Final.jar
hibernate-core-4.2.6.Final.jar
hibernate-jpa-2.0-api-1.0.1.Final.jar
itext-4.2.1.jar
javassist-3.15.0-GA.jar
javax.inject-1.jar
javax.servlet-api-3.1.0.jar
javax.servlet.jsp.jstl-api-1.2.1.jar
jboss-logging-3.1.0.GA.jar
jboss-transaction-api_1.1_spec-1.0.1.Final.jar
jcl-over-slf4j-1.7.5.jar
jcommon-1.0.17.jar
jdom-2.0.2.jar
jfreechart-1.0.15.jar
jna-4.0.0.jar
jsinterop-annotations-1.0.2-sources.jar
jsinterop-annotations-1.0.2.jar
libs.txt
log4j-1.2.17.jar
mchange-commons-java-0.2.3.4.jar
mysql-connector-java-5.1.26.jar
objenesis-1.3.jar
openhtmltopdf-core-0.0.1-RC4.jar
openhtmltopdf-log4j-0.0.1-RC4.jar
openhtmltopdf-pdfbox-0.0.1-RC4.jar
poi-3.9.jar
poi-ooxml-3.9.jar
poi-ooxml-schemas-3.9.jar
sac-1.3.jar
simple-xml-2.7.1.jar
slf4j-api-1.7.5.jar
slf4j-simple-1.7.5.jar
spring-aop-4.2.5.RELEASE.jar
spring-beans-4.2.5.RELEASE.jar
spring-context-4.2.5.RELEASE.jar
spring-context-support-4.2.4.RELEASE.jar
spring-core-4.2.5.RELEASE.jar
spring-expression-4.2.5.RELEASE.jar
spring-jdbc-4.2.5.RELEASE.jar
spring-jms-4.0.9.RELEASE.jar
spring-orm-4.2.5.RELEASE.jar
spring-oxm-4.0.9.RELEASE.jar
spring-retry-1.1.2.RELEASE.jar
spring-security-config-4.0.4.RELEASE.jar
spring-security-core-4.0.4.RELEASE.jar
spring-security-web-4.0.4.RELEASE.jar
spring-tx-4.2.5.RELEASE.jar
spring-web-4.0.9.RELEASE.jar
spring-webmvc-4.0.9.RELEASE.jar
spring-ws-core-2.2.4.RELEASE.jar
spring-ws-support-2.2.4.RELEASE.jar
spring-xml-2.2.4.RELEASE.jar
spring4gwt-0.0.1.jar
standard.jar
validation-api-1.0.0.GA-sources.jar
validation-api-1.0.0.GA.jar
xml-apis-1.3.04.jar
xmlbeans-2.3.0.jar
xpp3-1.1.3.3.jar




In Eclipse, using the "Open Type" dialog, I can only find one
"org.apache.juli.logging.Log" and only one
"org.eclipse.jetty.apache.jsp.JuliLog", both are included in "gwt-dev.jar".

I'm currently stuck and do not know how to proceed from here.


Any advice is much appreciated !


Thanks a lot in advance


Kind regards,
Leto

[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" ?
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).

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)

Post by Leto
Hello,
I recently had to upgrade a project from GWT 2.6.0 to GWT 2.8.2, while, at
the same time, the project migrated from Java 6 to Java 8, including a new
version of the IDE, namely Eclipse Oxygen.
For developing, we start the Super Dev Mode via an Ant script, which opens
the window where one can click on "Launch default browser" to open the GWT
app.
Unfortunately, upon opening the GWT app (clicking on the "Launch default
browser" button), I'm facing the following exception (shown in the console
HTTP ERROR 500
Server Error
javax.servlet.ServletException: java.util.ServiceConfigurationError: org.
apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not
a subtype
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:358)
107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
812)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(
ServletHandler.java:1669)
at org.springframework.security.web.
FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:316)
at org.springframework.security.web.access.intercept.
FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:126)
[...]
Caused by: java.util.ServiceConfigurationError: org.apache.juli.logging.
Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239)
at java.util.ServiceLoader.access$300(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java
:376)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.apache.juli.logging.LogFactory.<init>(LogFactory.java:78)
at org.apache.juli.logging.LogFactory.<clinit>(LogFactory.java:66)
at org.apache.jasper.runtime.TagHandlerPool.<clinit>(TagHandlerPool.
java:42)
at org.apache.jsp.Login_jsp._jspInit(Login_jsp.java:40)
at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:49)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(
JspServletWrapper.java:180)
at org.apache.jasper.servlet.JspServletWrapper.service(
JspServletWrapper.java:369)
[...]
-
https://stackoverflow.com/questions/43527854/upgrading-gwt-from-2-1-1-to-2-8-0-serviceconfigurationerror-org-apache-juli-lo
- https://github.com/tbroyer/gwt-maven-plugin/issues/65 ("GWT Eclipse
Plugin Running DevMode throws the famous jetty exception. #65")
- https://github.com/gwtproject/gwt/issues/9343 ("Jetty Exception
Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype #9343")
But neither of those were of help for me - maybe because I'm lacking some
experience with GWT and Java web apps in general.
<target name="dev" depends="javac" description="Super Dev Mode">
<path id="gwtDevModeClasspath">
<pathelement location="src" />
<path>
<pathelement location="${classes}" />
<pathelement location="${env.GWT_HOME}/gwt-user.jar" />
<fileset dir="${env.GWT_HOME}" includes="gwt-dev*.jar"
/>
<fileset dir="${lib}">
<include name="gin-2.1.2.jar" />
<include name="guice-3.0.jar" />
<include name="javax.inject-1.jar" />
<include name="aopalliance-1.0.jar" />
<include name="guice-assistedinject-3.0.jar" />
<include name="gwt-visualization-1.1.2.jar" />
</fileset>
</path>
</path>
<java failonerror="true" fork="true" classname=
"com.google.gwt.dev.DevMode">
<classpath>
<path refid="gwtDevModeClasspath" />
</classpath>
<jvmarg value="-Xmx256m" />
<jvmarg value="-Xss8m" />
<jvmarg value="-Dgwt.codeserver.port=9876" />
<jvmarg value=
"-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"
/>
<jvmarg value=
"-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"
/>
<arg value="-startupUrl" />
<arg value="MyApp.html" />
<arg value="com.MyApp.MyApp" />
<arg value="-logLevel" />
<arg value="INFO" />
</java>
<echo>${toString:gwtDevModeClasspath}</echo>
</target>
After the dev mode GUI window has been closed, I print the used classpath
D:\[...]\gwt-2.8.2\gwt-user.jar
D:\[...]\gwt-2.8.2\gwt-dev.jar
D:\[...]\Eclipse\MyGwtApp\src
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\classes
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\aopalliance-1.0.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\gin-2.1.2.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\guice-3.0.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\guice-assistedinject-3.0.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\gwt-visualization-1.1.2.jar
D:\[...]\Eclipse\MyGwtApp\war\WEB-INF\lib\javax.inject-1.jar
There are quite a few libraries in the "WEB-INF/lib" directory, which the
aopalliance-1.0.jar
c3p0-0.9.2.1.jar
chart-2.2.1.jar
dom4j-1.6.1.jar
dozer-5.5.1.jar
gin-2.1.2.jar
gson-2.8.5.jar
guice-3.0.jar
guice-assistedinject-3.0.jar
gwt-servlet.jar
gwt-user-2.8.2.jar
gwt-visualization-1.1.2.jar
gwt-vl-2.0b-without-hibernate.jar
hamcrest-core-1.3.jar
hibernate-commons-annotations-4.0.2.Final.jar
hibernate-core-4.2.6.Final.jar
hibernate-jpa-2.0-api-1.0.1.Final.jar
itext-4.2.1.jar
javassist-3.15.0-GA.jar
javax.inject-1.jar
javax.servlet-api-3.1.0.jar
javax.servlet.jsp.jstl-api-1.2.1.jar
jboss-logging-3.1.0.GA.jar
jboss-transaction-api_1.1_spec-1.0.1.Final.jar
jcl-over-slf4j-1.7.5.jar
jcommon-1.0.17.jar
jdom-2.0.2.jar
jfreechart-1.0.15.jar
jna-4.0.0.jar
jsinterop-annotations-1.0.2-sources.jar
jsinterop-annotations-1.0.2.jar
libs.txt
log4j-1.2.17.jar
mchange-commons-java-0.2.3.4.jar
mysql-connector-java-5.1.26.jar
objenesis-1.3.jar
openhtmltopdf-core-0.0.1-RC4.jar
openhtmltopdf-log4j-0.0.1-RC4.jar
openhtmltopdf-pdfbox-0.0.1-RC4.jar
poi-3.9.jar
poi-ooxml-3.9.jar
poi-ooxml-schemas-3.9.jar
sac-1.3.jar
simple-xml-2.7.1.jar
slf4j-api-1.7.5.jar
slf4j-simple-1.7.5.jar
spring-aop-4.2.5.RELEASE.jar
spring-beans-4.2.5.RELEASE.jar
spring-context-4.2.5.RELEASE.jar
spring-context-support-4.2.4.RELEASE.jar
spring-core-4.2.5.RELEASE.jar
spring-expression-4.2.5.RELEASE.jar
spring-jdbc-4.2.5.RELEASE.jar
spring-jms-4.0.9.RELEASE.jar
spring-orm-4.2.5.RELEASE.jar
spring-oxm-4.0.9.RELEASE.jar
spring-retry-1.1.2.RELEASE.jar
spring-security-config-4.0.4.RELEASE.jar
spring-security-core-4.0.4.RELEASE.jar
spring-security-web-4.0.4.RELEASE.jar
spring-tx-4.2.5.RELEASE.jar
spring-web-4.0.9.RELEASE.jar
spring-webmvc-4.0.9.RELEASE.jar
spring-ws-core-2.2.4.RELEASE.jar
spring-ws-support-2.2.4.RELEASE.jar
spring-xml-2.2.4.RELEASE.jar
spring4gwt-0.0.1.jar
standard.jar
validation-api-1.0.0.GA-sources.jar
validation-api-1.0.0.GA.jar
xml-apis-1.3.04.jar
xmlbeans-2.3.0.jar
xpp3-1.1.3.3.jar
In Eclipse, using the "Open Type" dialog, I can only find one
"org.apache.juli.logging.Log" and only one
"org.eclipse.jetty.apache.jsp.JuliLog", both are included in "gwt-dev.jar".
I'm currently stuck and do not know how to proceed from here.
Any advice is much appreciated !
Thanks a lot in advance
Kind regards,
Leto

[Leto]

Hello Thomas,

you answer is much appreciated, thank you!

Post by 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="-logLevel" />
<arg value="TRACE" />

but the only line containing the word "classpath" is

[java] 2018-07-02 13:18:18.743:INFO:/:main: No Spring
WebApplicationInitializer types detected on classpath

but I think this has nothing to do with the problem.

Post by Thomas Broyer
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.

Post by Thomas Broyer
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?


Thank you for any further help you can offer!

[Thomas Broyer]

Post by Leto
Hello Thomas,
you answer is much appreciated, thank you!

Post by 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="-logLevel" />
<arg value="TRACE" />
but the only line containing the word "classpath" is
[java] 2018-07-02 13:18:18.743:INFO:/:main: No Spring
WebApplicationInitializer types detected on classpath
but I think this has nothing to do with the problem.

Just to clarify: by "in the logs", I specifically meant the "Jetty" tab in
the DevMode window.

Post by Leto

Post by Thomas Broyer
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.

Post by Leto

Post by Thomas Broyer
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).

[Leto]

Hello Thomas,

sorry for my slow response, work schedule was a bit full the last days...

Eventually I could solve my problems and get it up running again - I really
appreciate your help Thomas, thank you!

Post by Thomas Broyer
Just to clarify: by "in the logs", I specifically meant the "Jetty" tab in
the DevMode window.

Oh I see. I checked it, there was no log message of the kind you mentioned.

Post by Thomas Broyer
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.

Thanks for the explanation, that might be the problem. I was not able to
check that, but fortunately, I could solve the problem by using a separate
webserver, as you suggested.

Post by Thomas Broyer
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).

It is really helpful that you took the time to describe the process, now I
understand it way better.


I ended up using the Eclipse Jetty Plugin to start my webapp and I created
an Ant task to start the CodeServer like this:

<java failonerror="true" fork="true" classname=
"com.google.gwt.dev.codeserver.CodeServer">
<classpath>
<path refid="gwtCodeServerClasspath" />
</classpath>

<jvmarg value="-Xmx1200m" />

<arg value="-launcherDir" />
<arg value="war" />
<arg value="-logLevel" />
<arg value="INFO" />
<arg value="-port" />
<arg value="9876" />
<arg value="de.myapp.MyWebApp" />
</java>


This setup works for me.

Just out of curiosity: Is there a difference between launching the DevMode
with "-noserver" and CodeServer with "-launchDir"?



Thomas, thanks again for taking the time to help!


Kind regards

[Thomas Broyer]

Post by Leto
Just out of curiosity: Is there a difference between launching the DevMode
with "-noserver" and CodeServer with "-launchDir"?

No, it will make no difference.