@Thomas: thanks a lot for the insight... Yes, you are correct I only use the embedded Jetty Server to serve (development-only) static HTML page. And I won't ever need more than this...
So then I think, I don't really understand what @Elias means sofar... I thought, he had the same installment like my structure? Damn already work with GWT since 2008 but still cannot see what the difference using devmode in my case and in @Elias case... :-) :-) I had once this structure: https://github.com/interseroh/demo-gwt-springboot but today I won't do this anymore... The classpath is a very big problem here... @Elias: Is there any problem to move to the structure like I have here in this example? https://github.com/gwtboot/domino-rest-enum-date I once write this tool MoveToMaven: https://github.com/crowdcode-de/MoveToMaven to move Ant projects to Maven projects. Actually it is not that complex to write such a tool to move your "old" GWT Maven structure to the new GWT Maven structure automatically. It's good to have such a transformer if you have a lot of Maven projects... Thanks, Lofi [email protected] schrieb am Dienstag, 4. Mai 2021 um 10:20:53 UTC+2: > 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 [email protected] wrote: > >> 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/2b5d02b6-585b-48b7-a4d8-39eaa70bfa1en%40googlegroups.com.
