Proposal: external server wiring for DevMode

[eliasbalasis]

In relation to gwt-plugins/gwt-eclipse-plugin#477

This would let those different versions be decoupled from GWT itself, so that GWT doesn't somehow need to bake in each possible version of each servlet container that someone might want to use. The mechanism to do this already exists in GWT - extend the com.google.gwt.core.ext.ServletContainerLauncher type and return a com.google.gwt.core.ext.ServletContainer instance when the server is started. This will almost certainly require some classloader trickery to keep your client code correctly separated from your server, but it is definitely possible to do. The better solution though is to have proper separation between your client and server code - separate classpaths, and run with separate processes.

and continuing from #9863

It sounds like we need a separate launchers GitHub project to hold all implementations of custom ServletContainerLauncher but supporting different Servlet flavors as well.
for example: one built against javax.servlet and one built against jakarta.servlet
so that we can attach the compatible one, matching the Servlets flavor of GWT.

Can we consider creating an external server wiring that lets DevMode start a separate server ?
supporting different servlet flavors and not sharing classpaths

[eliasbalasis]

see https://github.com/arquillian

[niloc132]

Thanks for filing this - are you interested in developing or sponsoring this work?

I imagine this to be an external project (or family of projects) to start with, then adopted to gwtproject and maintained collectively going forwards? It probably can start with a single implementation and generalize from what is learned there.

I think a developer would naively assume that such a tool would use a specific classloader for the server rather than something like Cargo, since that would still make it necessary to debug an external process. With that said, Cargo does have the benefit of nudging the user down the path of maintaining them separately, as they likely already have a way to run their server without GWT at all - and it seems plausible that a single Cargo implementation could handle all the various implementations that it in turn supports.

Other considerations:

• As pointed out, we'll want to make sure that these tools play nicely with IDE plugins - do we want to encourage an uberjar for each that holds the entire servlet container? Probably better to have a directory of jars, or a command to run that downloads all dependencies from maven into a single directory to point at.
• With this on the horizon we should start considering flipping the default from Proposal: Deprecate DevMode usage without -noserver #9863 to the new static-only server, and a version or two later removing the Jetty implementation entirely. This will enable updating Jetty in GWT itself with no side effects for users. There are more considerations here too that could lead us to consider dropping Jetty entirely - Jetty 11 is End of Community Support and tentatively planned to be EoL soon, and Jetty 12 requires a minimum of Java 17. Ticket filed as Change default dev mode server to static implementation #10057.
• There will probably not be more than 2-3 (StaticResourceServer, JettyLauncher, and the user's own added preference) implementations of ServletContainerLauncher on the classpath at a time, and they will probably have unique names (if we ignore packages). A service loader could be devised that picks up registered implementations, asks their names, and checks for which matches the user's entry. This would lower the barrier to entry slightly, letting the user pass only -server jetty12 to activate the com.example.gwt.jetty12.Jetty12ServletLauncher implementation. This could be handy in other places too, such as junit RunStyle implementations. Ticket filed as Consider service loader for picking up custom implementations  #10058.

[eliasbalasis]

Cargo is a good idea.
I will examine.

I can see JettyLauncher etc. disappearing eventually, primarily in favor of external server wiring but also in relation to maintenance headaches and related struggles.

Regarding tooling, I would initially let projects add the required JARs to the DevMode classpath and eventually make the external servers part of "GWT Eclipse Plugin".