I am fully aware that spawning a separate JVM carries its own complications.
I have provided embedded flavours for Jetty 9,10 and 11 but I am afraid, as I pointed out above, I have met further complications. At this point I am rather at a dead end, at least with Jetty. On Saturday, 19 April 2025 at 23:06:09 UTC+2 Wejden Mrabti wrote: Hi everyone, Recently, I’ve been working on migrating our GWT application (Java 17 – GWT 2.12.2) to run on *Jetty 11.0.25*, and I followed the approach described by @elias using the *Cargo API* to launch the app in DevMode. Here’s what I’ve done so far: - I'm launching the app on eclipse IDE with: -war my_war_path -server net.upperlimit.tools.GWT.DevMode.server.impl.Cargo.installed.Jetty11.jakarta.DevModeServerLauncher - Since debugging didn’t work out-of-the-box from Eclipse, I tried attaching a *Remote Java Application* configuration. - To support that, I *overrode the DevModeServerLauncher* to expose *JDWP arguments* via VM options, with: -DdebuggerPort=5007 -DdebuggerSuspend=n - This allows me to debug *server-side code* from Eclipse, but *client-side debugging (GWT)* remains tricky, and *Super Dev Mode / hot code reloading* doesn't seems to work properly. So far this setup (based on an *installed Jetty instance*) feels a bit cumbersome and disconnected from the Eclipse workflow. It seems to spawn a separate JVM, which complicates debugging and classpath management. I’m wondering if there’s a recommended way to launch the app using the *"embedded Jetty" approach*, ideally within *Eclipse*, to better match developer expectations — single JVM, smoother debugging, and working hot reload. Any advice, working examples, or gotchas would be greatly appreciated! Thanks a lot in advance! Le vendredi 4 avril 2025 à 19:20:25 UTC+2, [email protected] a écrit : 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/7da3355b-35db-49ac-affa-97b5ed5394b1n%40googlegroups.com.
