0.0.29 is now being published to Maven Central at https://central.sonatype.com/artifact/io.bitbucket.upperlimit-public/GWT-DevMode-server.BOM/0.0.29
still carrying a temporary but required workaround for https://github.com/gwt-plugins/gwt-eclipse-plugin/issues/515 with support for service loader mechanism introduced in GWT 2.13 On Thursday, 4 September 2025 at 14:13:42 UTC+1 [email protected] wrote: 0.0.27 has been published to Maven Central with a temporary workaround for https://github.com/gwt-plugins/gwt-eclipse-plugin/issues/515 Official adoption could be the next step, if there is interest. On Wednesday, 16 July 2025 at 00:45:33 UTC+1 [email protected] wrote: I am afraid there are still classpath issues and I am afraid these are possibly related to https://github.com/gwt-plugins/gwt-eclipse-plugin/issues/515 On Tuesday, 8 July 2025 at 12:46:29 UTC+1 [email protected] wrote: Version 0.0.24 has been published to Maven Central. It contains support for Tomcat embedded launcher in modules GWT-DevMode-server.impl.Cargo.embedded.Tomcat9.javax , GWT-DevMode-server.impl.Cargo.embedded.Tomcat10.jakarta , and GWT-DevMode-server.impl.Cargo.embedded.Tomcat11.jakarta see https://bitbucket.org/upperlimit-public/gwt-devmode-server/src/main/ see https://central.sonatype.com/search?namespace=io.bitbucket.upperlimit-public On Friday, 13 June 2025 at 18:21:26 UTC+1 [email protected] wrote: Returning to this effort and given the challenges I have so far faced with running an embedded variant of Jetty I have decided to experiment with embedding of other servlet containers, in hope of dealing with the classpath issues I encountered. Tomcat was my first thought. On Monday, 21 April 2025 at 07:32:09 UTC+1 ILIAS BALASIS wrote: That’s exactly what the modules classified as “installed” do, downloading and unpacking the servlet container release archive locally. The download URL is configurable using JVM properties. I intend to add this to the launchers project page. This seems to be working at least for trivial projects so far but it is disconnected from standard development operations flow. Running in the same JVM unfortunately presents other challenges, classpath conflicts mostly, which I have been unable to resolve so far for non-trivial projects. ------ Original Message ------ >From "Jens" <[email protected]> To "GWT Contributors" <[email protected]> Date 20/04/2025 23:04:57 Subject Re: [gwt-contrib] Re: Official external DevMode server implementations Would it be too bad to not use embedded container but instead installed container <https://codehaus-cargo.github.io/cargo/Installed+Container.html> with Cargo? They also provide a simple Java API to download and unpack a servlet container release archive locally. So DevMode could download and install a servlet container in a GWT specific location and then use that. The download URL could also be made configurable using a gwt-devmode.properties file in the project similar to how the gradlew script installs gradle locally if needed. Cargo documentation explicitly says that embedded containers can quickly end up in classloader / JAR hell and have other downsides: https://codehaus-cargo.github.io/cargo/Embedded+Container.html -- J. [email protected] schrieb am Freitag, 4. April 2025 um 19:20:25 UTC+2: I understand. I am actually loading all Jetty classes using a custom child-first classloader and let everything else be loaded by the parent classloaders chain. That was expected to be sufficient but apparently it is not, a lot of trickery is still required. On Friday, 4 April 2025 at 18:12:19 UTC+1 Thomas Broyer wrote: On Fri, Apr 4, 2025 at 6:48 PM [email protected] <[email protected]> wrote: Relatively solved indeed, that's what I expected, which worked for my PoC modules. The first problem I encountered was loading some application classes through the DevMode launcher's classloader and some others from the application classloader. for example: SpringFramework interfaces loaded from the isolated DevMode classloader but concrete implementation classes loaded from the application classloader, which produced class loading errors. I had to start excluding dependencies from the Jetty container's WEB-INF/lib folder using a specific technique so that the classes would be all loaded from the classloader of DevMode instead, but even that wasn't enough. The problem got worse when I tried to make use of even more dynamic frameworks like SpringSecurity, being unable to prepare the underlying component chains, which is where I stopped. Overall, it seems that even though the DevMode classloader is isolated, a lot of trickery may still be required. I haven't looked at the code, but in case you were on that path: please do not try to mimic the current behavior where server-side classes can be loaded from the classpath. Having a breaking change like this is a great opportunity to ditch that and just require that server-side classes are within WEB-INF/classes and WEB-INF/lib. That way, you use the server's already implemented and battle-tested classloaders respecting the Jakarta Servlet specs for precedence and isolation. That custom classloader was the main reason Jetty wasn't updated more often (in addition to changing its API in minor or even patch releases). -- 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]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/1228184a-52d6-409a-8f35-fc2894cb4413n%40googlegroups.com <https://groups.google.com/d/msgid/google-web-toolkit-contributors/1228184a-52d6-409a-8f35-fc2894cb4413n%40googlegroups.com?utm_medium=email&utm_source=footer> . -- 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]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8f2d8015-e424-4e9b-aa7a-cc8a4665a930n%40googlegroups.com.
