My 2 cents, I understand very well where "Lofi" is coming from.
He tries to simplify the GWT server-side by moving all the potentially conflicting classpath dependencies to a separate application. This recipe indeed involves an extra step but it doesn't change at all the situation with "DevMode+Jetty" and the associated classpath misalignment, particularly with GWT 2.9+ while the "DevMode+Jetty+CodeServer" combination still runs in a single step. Therefore, I still vote in favor of keeping DevMode, removing support for Java7, upgrading Jety to more recent version and use of same transitive dependencies between GWT and Jetty (e.g. ASM). FYI, if it helps anyone, I have found a workaround to the classpath misalignment issue (see https://github.com/gwtproject/gwt/issues/9693#issuecomment-822016533) which works both for GWT2.9+ and previous versions. On Tuesday, 4 May 2021 at 08:53:21 UTC+1 t.br...@gmail.com wrote: > On Tue, May 4, 2021 at 3:15 AM 'Lofi Dewanto' via GWT Contributors < > google-web-tool...@googlegroups.com> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/da8026bb-33df-47aa-a975-2843c99af7bfn%40googlegroups.com.
