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.
