On Tue, May 4, 2021 at 3:15 AM 'Lofi Dewanto' via GWT Contributors < [email protected]> wrote:
> What I don't understand so far, why does Jetty disturbs the whole > classpath concept? There are many issues, depending on who you ask and how they use GWT. The issue that started this discussion about upgrading Jetty is that Jetty scans the WEB-INF/lib JARs, and the version we use in GWT will fail on any module-info.class. Other issues with how Jetty is used in DevMode is that we give it a special WebAppClassLoader that doesn't work like a standard web-app classloader in that it will resolves classes from both the WEB-INF/classes and WEB-INF/lib, and the DevMode classpath. This was done so that you don't need to "assemble" an "exploded WAR" (compiling your server code to WEB-INF/classes, putting your server dependencies to WEB-INF/lib). This has caused *many* issues over the years (Spring failing because it saw its configuration twice: from the WEB-INF/classes and from the classpath; some libraries from the classpath leaking to the web-app classloader; etc.), and makes upgrading Jetty is unnecessarily hard and error-prone (last time we did, I spent hours fixing it). And I'm not even talking about people asking for JSP support, or jetty-web.xml support (e.g. to configure form authentication or JNDI resources), or web-fragments, annotation scanning (that's now causing the issues with modules) Everything would be much much simpler if we removed all those features to only support the bare minimum (static files), or possibly re-introduce the <servlet> support in gwt.xml (and totally removing web.xml support), or as a last resort making it extra-clear that this only supports "demo-size" projects (after we remove the custom classloader, and possibly JSP and jetty-web.xml) and that if it breaks or you need more features then you just don't use it. The last issue is actually a non-issue (and that was actually Elias' problem, or at least part of it): people misconfiguring their classpath and including other Jetty or servlet libraries in the classpath. We can't do anything here, that's a classpath management issue and it would be the same with many other dependencies (e.g. upgrade HTMLUnit, you'll see your tests fail). > *I only use devmode on the client *and on the client I don't have server > libs... Is it not possible just to use the needed Jetty server for GWT (I'm > not sure where else do we need the Jetty libs in GWT code)? Jetty is used for the CodeServer itself (that could probably be migrated to using com.sun.net.httpserver), and for the JUnitShell (that one needs to support basic servlets, so no com.sun.net.httpserver here). And the Jetty version needs to be aligned with what HTMLUnit uses, as it requires some Jetty client libraries (mostly for websocket support IIRC) that transitively require some Jetty "common" libraries (jetty-util, jetty-io). > Because actually I don't care what version of Jetty should be used in > GWT... the main thing: *I could run web server + code server in the same > process *with one execution. I don't really get what point you're trying to make. If you don't have server code in your DevMode, then you're not impacted by the change being discussed here. Another possibility: run the Jetty for devmode in the GWT Maven plugin? So > you only have the Jetty on the classpath of the Maven plugin? > > To show you my use case, here is an example: > https://github.com/gwtboot/domino-rest-enum-date > Where you're starting your Spring Boot server separately from DevMode (so you have 2 processes, not just one, contrary to what you're saying above), whose embedded server only serves a (development-only) static HTML page. That's probably not how I would work with Spring Boot, but indeed that works too. -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> -- 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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAEayHENB%3D8WqxLP%3D5uGNgXcjcjL0HKbncJNRJQQVoN4pZQHUSw%40mail.gmail.com.
