Proposal: Deprecate DevMode usage without -noserver

[niloc132]

For many years, it has been suggested that non-trivial applications should bring their own server, and not rely on the Jetty instance built-in to GWT's DevMode to host their app, even for development purposes. There are many reasons to say this, and with a new one arising, it may be time to formally deprecate this.

The javax.servlet -> jakarta.servlet transition makes it hard for a single container to serve both old and new applications. Inevitably, there will still be javax.servlet applications running for many years, even though most app servers have deprecated or end-of-life'd their implementations by now.

Jetty in particular is interesting for us, as GWT DevMode and CodeServer are based on Jetty. Their versioning policy has Jetty 9, the version that GWT currently uses, at end-of-life. Jetty 10 will probably be maintained for at least a few more years, and while it supports javax.servlet, it does require Java 11. Jetty 11 and 12 are both stable releases as well, but require jakarta.servlet. This deprecation would remove the need to offer a migration timeline/path for DevMode to transition to jakarta.servlet.

---

This issue proposes to deprecate usage of DevMode as an application server, potentially moving to a default of -noserver, and potentially removing -server entirely in the future. Unlike some other deprecations, this should cause no loss in functionality for end users, as (I dearly, dearly hope) no application in the world is actually deployed on DevMode, but already has an appropriate application server that it can use.

My proposed implementation for GWT 2.11 is to log once on startup if an application is being served. The simplest check here could be a filter on /* - any traffic at all triggers a single warning message - this would not log until such a call was made. Alternatively if we wanted to allow only trivial "static files only" apps, we could query the JettyLauncher's ServletHolder to see if any servlets or filters were configured, and if so, log at the end of startup that this usage was deprecated.

A future implementation where -noserver was the default could instead warn if -server was specified at all.

[tbroyer]

Fwiw, I'd rather deprecate the use of servlets only, and at one point move to remove servlet support altogether, only supporting static files (possibly with a "catch-all" mode that returns the index.html for all URLs; if anyone finds that useful).

IMO, deprecating -server altogether would be equivalent to deprecating DevMode and asking everyone to use CodeServer, and much simpler to implement 😉

[eliasbalasis]

IMO, deprecating -server altogether would be equivalent to deprecating DevMode and asking everyone to use CodeServer, and much simpler to implement 😉

You are still trying to make everyone change their ways, aren't you?
Please don't, there are many teams out there whose development process relies on DevMode, many of my teams to say the least.

[tbroyer]

How is DevMode with -noserver different from CodeServer?

If you're still using DevMode without -noserver then this whole proposal is trying to make you change your ways.

[eliasbalasis]

We are not using DevMode with -noserver, that's the problem.

And yet you seem to be suggesting that use of DevMode with -noserver is the correct and only way to test GWT applications, unless I have misunderstood.

Also:

-server Specify a different embedded web server to run (must implement ServletContainerLauncher)

I am of the opinion that it is fine to deprecate this as long as Jetty remains the default and won't be deprecated.

Would it be fair to say that on GWT 2.11+ only jakarta.servlet should be used? to remove the maintenance burden, which I understand is heavy, in which case we may not have to deprecate -server.

Please correct me if I have misunderstood something.

[tbroyer]

And yet you seem to be suggesting that use of DevMode with -noserver is the correct and only way to test GWT applications, unless I have misunderstood.

Well, I am not, this proposal is (and I happen to agree)

Fwiw, as far as maintenance burden goes, one middle-ground could be to still allow running servlets but disable everything else, particularly the classloading tricks (i.e. your classes have to be in WEB-INF/classes and your dependencies in WEB-INF/lib). But as said in the rationale above, this would mean switching from javax to jakarta at some point, which will assuredly cause burden to developers, and require planning for GWT maintainers.

I don't think -server (as a plugin-enabler) is really a maintenance burden though (from GWT's PoV; developers of such "plugins" will still have to juggle with dependency conflicts as GWT lives its life and evolves), so one could possibly reproduce the current logic on their own if they really want it.

[eliasbalasis]

this proposal is (and I happen to agree)

Like I said and I have repeated elsewhere in the past,
DevMode with embedded server is still useful and should not be deprecated.

Please let's not sacrifice this.

classloading tricks

On certain occasions these may be required and it is not a GWT fault.
For teams finding this difficult to deal with, I would suggest moving to -noserver.

would mean switching from javax to jakarta at some point

I agree, it is inevitable and it will require transformation effort, only once though (hopefully).

I don't think -server (as a plugin-enabler) is really a maintenance burden though

I agree, no need to sacrifice extensibility.

[niloc132]

@tbroyer two points to your first reply:

• Dropping DevMode entirely would still let a project serve static content, if we're looking to go in that direction - the public/ directory will always be copied and served. For simple static projects that may well be more than enough. Downside: the contents are copied, and only when the compile runs. Obvious upside, we shed an enormous amount of legacy code.
• On the other hand, dropping DevMode means losing legacy dev mode (which still technically works on at least Java 11/17 and probably 23, if you provide the correct JVM args), something we've only discouraged and not formally deprecated yet. Keeping DevMode and defaulting to -noserver also leaves the opportunity to leave the -server <fqcn> feature intact (as you alluded to) , where a project can specify their own implementation of ServletContainerLauncher (which despite the name, is completely servlet-agnostic) - projects can make the informed decision to maintain their own implementation.

So perhaps GWT 2.11 warns if servlets are in use, GWT 2.12 changes the default to -noserver (and potentially moves to Jetty 10), and GWT 2.13 removes the default ServletContainerLauncher implementation? Technically, JUnitShell still uses JettyLauncher too, but at that time we could reduce the scope of classloader hacks to only what tests require - a user could explicitly specify JettyLauncher as their implementation, as long as it continues to exist for testing purposes.

...We probably will also need to either deprecate <servlet path=... class=... /> in .gwt.xml files, or inevitably provide an optional adapter from javax->jakarta.

---

@eliasbalasis I don't take this lightly at all, but as I laid out in my introduction, breaking changes here are inevitable. Even if you happen to be a paying customer of Webtide (the company who provides most of free/paid support and development for Jetty), it appears that they anticipate the actual end of Jetty 9 to be around 2025, otherwise there are no further updates. As above, dropping Java 8 support could let Jetty 10 serve as a non-breaking change for a brief window, but given that 11 and 12 are both released and stable, 10 probably has an end in sight as well. And of course, Jetty 11+ means we "make everyone change their ways" and update to jakarta.servlet, which is doubtlessly going to cause some upheaval as well.

Dropping JettyLauncher in GWT 2.12 or 2.13 but still keeping the -server flag may offer the smoothest path forward, enabling teams to maintain their own embedded server implementation, making the transition to jakarta on their own time, and dealing with any classloader changes that may arise in a way that suits them best.

As an aside, Vertispan offers paid support for GWT, and GWT has its own OpenCollective account for teams that wish to more directly fund GWT's development and maintenance. I know of exactly zero Vertispan support customers or GWT supporters who require Java 8, legacy DevMode, or DevMode-as-an-app-server, but we are still supporting these cases to the best of our ability. This is a substantial amount of work when other updates are performed, and if it is truly important to you, I encourage you to find a way to help: either with your own development time, or through funding someone else's. GWT is often said to be "dead", which I interpret as "working, stable, and maintained: thus boring" - we want to keep it boring, but external dependencies motivate changes like this.

[jnehlmeier]

Jetty 11 and 12 are both stable releases as well, but require jakarta.servlet

@niloc132 That is not entirely true. Jetty 12 has been modularized with regard to EE versions. You can use Jetty 12 and let it start web applications for EE8, EE9, and EE10 in parallel. They achieved that by tripling all servlet spec relevant jetty modules and introduced an additional class loading layer.

So you can enable jetty module ee8-deploy only and all web applications are treated as EE8 web applications. However you can also enable modules ee8-deploy, ee9-deploy, ee10-deploy together. Then by default any web application will be treated as the highest enabled EE version, in this case EE10. If you place a *.properties file next to the *.war file (both must have the same name) you can tell jetty for that single web application which EE environment to use.

So with Jetty 12 GWT could potentially support javax.servlet and jakarta.servlet at the same time using just one Jetty in gwt-dev.jar.

But of course time will come that Jetty will drop support for the ee8 and ee9 modules. Well and Jetty 12 requires Java 17 to launch. So GWT would need to decide to skip Java 11 completely. Personally I would be fine with it if any library only supports the current and the last LTS Java release.

Personally I am using Jetty 12 with EE8 and it works very well.

With that being said I strongly believe that everybody should use the same server in development as in production including the same configuration as much as possible. That is why I also always suggested to not use the embedded server at all. Because of the classloader hacks it was easy to have a working web application in development that failed to deploy in production because some classes were missing in WEB-INF/lib or have accidentally been used in code for projects that have a single classpath for client + server code.

However I also think that the out of the box experience needs to be great nowadays. I can very well remember being all new to web development and evaluating GWT the first time. Of course I had also evaluated GWT-RPC back in the days and it was very easy to get running. I had no idea about configuring jetty or any other application server, so it would have been a real blocker during evaluation.

So if we kill support of deploying web applications out of the box, we need to provide an easy alternative that fits into a "QuickStart guide" for new people trying GWT, all of GWT including RequestFactory, GWT-RPC, server side stacktrace deobfuscation.

I can not remember how DevMode -noserver behaves out of the box. Is it required to launch a dedicated server that serves the index.html page which then talks to the CodeServer? The best experience would be that DevMode -noserver shows an URL that I can copy/past into the browser to see the app (compiling).

[niloc132]

Thanks for that @jnehlmeier - that certainly could make this transition more prolonged, if we decide it must be. I still anticipate that classloader problems will continue to plague us, but if nothing else we can offer this as a way to implement ServletContainerLauncher and still support old servlets.

When you launch DevMode -noserver, to my knowledge it is nearly the same as running CodeServer, except for

• It is technically still possible to start with legacy dev mode (that is, with -nosuperDevMode)
• CodeServer's -launcherDir is specified through a combination of -war <path> and -modulePathPrefix <path> (an option I have never seen used).

When calling DevMode -noserver, it is not required to run a dedicated server - static files could be placed in a public/ resources directory, or an html file can be loaded from a file:/// context. Updating documentation should be a component of this migration - I know we can easily point at the module-webapp Maven archetype, is there an analogous template to use for Gradle projects (or is this another "the tool is easy to understand if you already know how it works" expectation)? A concerted effort should probably be made to remove the Ant examples/scripts as well.

[niloc132]

@eliasbalasis (and others), can you comment on the current PR and plan to move forward? I will update docs and examples if we have consensus on this.

On that note... is there a canonical gradle example to run a server and codeserver/devmode? I'm aware of many individual plugins, but none that really manage the "how do you get started" problem.

PR: In short, there is a new built in "plugin" that can be explicitly passed to -server, and the expectation remains that users can implement their own ServletContainerLauncher, but JettyLauncher is deprecated, and will log warnings if used. I would happily encourage external (or even as another top-level project in github.com/gwtproject?) implementations of this, especially those that cleanly use classloaders to avoid depending on the internal Jetty implementation (or are prepared to manage their own breakage when the time comes to update Jetty).