Correction: Even though the DevMode launcher's classloader is isolated, a lot of trickery may still be required, to eliminate classloading issues and others I haven't been able to resolve yet or worse that I haven't come across yet.
So, I started thinking that if an isolated DevMode launcher classloader was not needed anymore, implying decoupling of Jetty from GWT, there would be fewer problems. On Friday, 4 April 2025 at 17:48:55 UTC+1 [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. > > 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/690b6b90-d4f0-4449-8508-ea8ead3a0321n%40googlegroups.com.
