That’s exactly what the modules classified as “installed” do,
downloading and unpacking the servlet container release archive locally.
The download URL is configurable using JVM properties.
I intend to add this to the launchers project page.
This seems to be working at least for trivial projects so far but it is
disconnected from standard development operations flow.
Running in the same JVM unfortunately presents other challenges,
classpath conflicts mostly, which I have been unable to resolve so far
for non-trivial projects.
------ Original Message ------
From "Jens" <[email protected]>
To "GWT Contributors" <[email protected]>
Date 20/04/2025 23:04:57
Subject Re: [gwt-contrib] Re: Official external DevMode server
implementations
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
<https://groups.google.com/d/msgid/google-web-toolkit-contributors/1228184a-52d6-409a-8f35-fc2894cb4413n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/emcc41c2a5-2f25-48d4-9a0b-876d6b35baf5%40940d2ed7.com.
