If you *want* conflicting Jetty versions, you could implement a ServletContainerLauncher type that calls out to another process to start jetty there. You could also get fancy with a separate ClassLoader for Jetty 11/12 types, but that seems a bit dangerous, you'd want to take great care to not accidentally end up with a reachable Jetty 9 class in there, or Jetty 11/12 class in the default app classloader. It has been informally discussed that this could be a good idea to provide as an extra library for those interested in using it (or tomcat, undertow, etc), but to my knowledge no one has started that work.
Thomas's original idea is still best - don't run your server types in DevMode, but start the server how you would if you weren't even writing GWT code at all. Then start DevMode/CodeServer, directing it where to write its generated JS files (as if some other JS dev tools were writing them) so your own server can pick them up. Now you can never have these conflicts.
On Wednesday, December 11, 2024 at 1:30:42 PM UTC-6 Thomas Broyer wrote:
On Wednesday, December 11, 2024 at 8:05:10 PM UTC+1 Fred Andrews wrote:Sadly, GWT 2.12.1 still contains bundled Jetty 9, which is incompatible with Servlet 5.0. Upon looking into it, I see that the suggestion is to override ServletContainerLauncher with my own implementation that launches Jetty 11+.The suggestion is to run them (server vs client code) in separate processes.I'm running GWT DevMode from an ant environment, so I updated the ant task to have the proper JARs for Jetty 11, overrode ServletContainerLauncher, and tried to launch DevMode. However, although DevMode does launch Jetty 11, the CodeServer crashes because of its dependence on javax - looking at the source I see that it has hardcoded javax imports.You could probably implement a ServletContainerLauncher based on something else than Jetty though (Tomcat, Undertow)So is it impossible to use the built-in CodeServer when you override ServletContainerLauncher? What's the point of DevMode without CodeServer?I see lots of suggestions to launch CodeServer separately, but even this may still have a problem. ChatGPT says that some shared client/server code may contain servlet class references, which means that CodeServer might be faces with compiling jakarta imports. This is going to fail obviously. So what's the guidance here? Is CodeServer dead too? Or is there a Jakarta-based CodeServer in GWT 2.12.1 too?The only cases of shared code referencing server code should be either GWT.create(MyRpcService.class), but even those shouldn't problems: because there's a change in package you can have javax.servlet and jakarta.servlet API JARs in the same classpath.(there's also the case of RequestFactory's @ProxyFor/@Service but those generally won't reference servlet classes; and you could change to @ProxyForName/@ServiceName to cut the reference)What you cannot do is have "conflicting" Jetty versions, because CodeServer directly uses Jetty and relies on its API, that changes with almost every release.Using distinct classpaths/processes is your best bet in the long run, even if that possibly mean making some (small) changes to your code.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/4d5f39fc-0eb1-485e-a644-c10e1ef0e983n%40googlegroups.com.
No comments:
Post a Comment