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/da885e17-977c-4c5b-9869-21d4fde7b276n%40googlegroups.com.
