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. On Friday, 4 April 2025 at 15:23:17 UTC+1 Colin Alworth wrote: Can you elaborate here, or in the issue tracker, on what doesn't work, or provide some example projects that demonstrate the issue? Decoupling GWT from the server it internally uses is likely a first step but could never be a last one - cases like this will continue to break if the server application ever shares any classes with anything on the server classpath - any wrong version of apache commons, JDT, htmlunit, etc could come back and bite us later if we don't have proper isolation. Servlet containers have successfully isolated running applications from each other for decades, and applications that understand they are being isolated in this way must recognize certain limitations, so this should be a relatively solved problem. On Thursday, April 3, 2025 at 1:25:20 PM UTC-5 [email protected] wrote: After having discovered further classpath/classloader complications trying to use my custom launchers within actual applications, I am leaning towards deciding to postpone further efforts, until Jetty gets decoupled from GWT. I will update if I discover any workaround that could keep the current effort going. On Wednesday, 26 March 2025 at 08:15:59 UTC [email protected] wrote: 0.0.17 <https://central.sonatype.com/artifact/io.bitbucket.upperlimit-public/GWT-DevMode-server.BOM/0.0.17> has been published to Maven central. see https://bitbucket.org/upperlimit-public/gwt-devmode-server/src/f5ed6ab9a21ebb737468e0e3f6d6e73f7f664662/?at=release%2F0.0.17 for details Keep watching Maven Central <https://central.sonatype.com/artifact/io.bitbucket.upperlimit-public/GWT-DevMode-server.BOM> and project home <https://bitbucket.org/upperlimit-public/gwt-devmode-server/src> regularly for updates. On Tuesday, 25 March 2025 at 15:28:27 UTC [email protected] wrote: 0.0.12 <https://bitbucket.org/upperlimit-public/gwt-devmode-server/src/47701b48b416d20aae0ee239468d569928a95d6b/?at=release%2F0.0.12> is out, supporting Jetty12 (ee10) On Tuesday, 18 March 2025 at 13:01:59 UTC [email protected] wrote: I have published the first version of the DevMode server implementations to Maven Central at https://central.sonatype.com/search?q=o.bitbucket.upperlimit-public <groupId>io.bitbucket.upperlimit-public</groupId> <artifactId>GWT-DevMode-server.impl.embedded.Jetty9.javax</artifactId> Server class net.upperlimit.tools.GWT.DevMode.server.impl.embedded.launcher.Jetty9.DevModeServerLauncher <artifactId>GWT-DevMode-server.impl.embedded.Jetty10.javax</artifactId> Server class net.upperlimit.tools.GWT.DevMode.server.impl.embedded.launcher.Jetty10.DevModeServerLauncher <artifactId>GWT-DevMode-server.impl.embedded.Jetty11.jakarta</artifactId> Server class net.upperlimit.tools.GWT.DevMode.server.impl.embedded.launcher.Jetty11.DevModeServerLauncher <artifactId>GWT-DevMode-server.impl.Cargo.installed.Jetty9.javax</artifactId> Server class net.upperlimit.tools.GWT.DevMode.server.impl.Cargo.installed.Jetty9.javax.DevModeServerLauncher <artifactId>GWT-DevMode-server.impl.Cargo.installed.Jetty10.javax</artifactId> Server class net.upperlimit.tools.GWT.DevMode.server.impl.Cargo.installed.Jetty10.javax.DevModeServerLauncher <artifactId>GWT-DevMode-server.impl.Cargo.installed.Jetty11.jakarta</artifactId> Server class net.upperlimit.tools.GWT.DevMode.server.impl.Cargo.installed.Jetty11.jakarta.DevModeServerLauncher Jetty12 implementation is facing a few obstacles but I am working on it... For those interested in experimentation, use DevMode with "-server" parameter set to the desired server implementation class in your GWT Plugin launch configuration and run. The server implementations under the "embedded" package run in the same JVM as DevMode but with isolated classpath, using a child-first class loader. This approach make classpath fixes possible because the servlet container runs in the same JVM as DevMode. The server implementations under the "installed" package start a servlet container on a separate JVM, which you can debug by passing the :debuggerPort=<port> option to the "-server" parameter. This approach cannot deal with classpath issues because the servlet container is running on a separate JVM. I intend to create alternative Jetty embedded implementations as soon as we manage to decouple Jetty from GWT. I can create more server implementations upon request but I would suggest caution not to create more than actually needed. Let me know your thoughts. On Thursday, 6 March 2025 at 20:56:50 UTC [email protected] wrote: Good point. Indeed, not too many kinds of servlet containers are needed. I have implemented embedded Jetty9, Jetty10 and Jetty11 so far. I am currently working on embedded Jetty12 with EE10 and I would consider EE8, EE9 and future variants. We could choose to make any of these official somehow. On Thursday, 6 March 2025 at 19:18:36 UTC Jens wrote: +1 to adopting and maintaining official implementations (disclaimer: knowing that I won't maintain them myself, but) not having at least "some" official implementations would likely be a show stopper; maybe only have a couple official implementations though, with limited scope (like nowaday's JettyLauncher), and leave the others as "third parties"? (also makes it easier to "abandon" some when/if hardly anybody uses them and/or they become a burden to maintain; and provide more guarantees for the "official" ones?) I agree that an official implementation should not cover all kinds of servlet containers. The more are supported officially the less an argument can be made to not support additional servlet containers (Where to draw the line?). For every officially supported servlet container implementation someone needs to track the releases, etc. Personally I would only provide Jetty 12 as the single official implementation because it supports EE8, EE9 and EE10 via configuration. That keeps the maintenance burden low while covering EE8-10 and possibly future EE versions. It also matches what GWT offers out of the box today. -- J. -- 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/b6bb78a6-b415-4f73-9189-da703cd4e520n%40googlegroups.com.
