Pull request making the proposed changes (and a bit more): https://github.com/AndrewAni/GwtDev/pull/1
On Monday, July 17, 2017 at 11:45:06 AM UTC+2, Thomas Broyer wrote: > > > > On Monday, July 17, 2017 at 11:11:46 AM UTC+2, Andrei Anishchenko wrote: >> >> Hi, >> >> I have a Maven multi-module project that uses Spring Framework in the >> backend. Everything was working fine until I tried to migrate from GWT >> 2.7.0 to 2.8.1. Supposedly production mode works fine (never tried though >> so far), but in SuperDev mode I am getting initialization errors coming >> from Spring bootstrap. Some built-in Spring beans require them to be >> created only once, while attempts to create several of them are taken (see >> the log file attached for an example). Digging into this, I discovered that >> it has something to do with the fix for >> https://github.com/gwtproject/gwt/issues/9292, namely, in >> com.google.gwt.dev.shell.jetty.JettyLauncher.WebAppContextWithReload.WebAppClassLoaderExtension#getResources >> >> <https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java#L373> >> >> method. Before this fix, Jetty's classloader loaded resources strictly from >> the lib folder of the web application, and now it is so greedy that it >> loads them both from this said folder AND local Maven repo. This makes all >> my Maven submodules available twice in the classpath, each if them is >> treated individually. >> >> To demonstrate the issue, I've created a simple application that >> resembles my original setup. This application is available here: >> https://github.com/AndrewAni/GwtDev >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FAndrewAni%2FGwtDev&sa=D&sntz=1&usg=AFQjCNFz5Nqz5CpspLot74BX24-cwQ1Njg>. >> >> If these >> <https://github.com/AndrewAni/GwtDev/blob/master/server/src/main/resources/applicationContext.xml#L5> >> >> two scheduler-related bean definitions are commented out, the problem >> doesn't present itself. >> >> It appears that if I go with Java-based Spring configuration, this >> wouldn't bother me anymore, since the suspicious classloader code affects >> only loading resources like XMLs. But I cannot shake the feeling that I am >> doing something wrong, and with the next GWT development iteration even >> Java classes would be loaded differently, breaking my stuff even more. >> >> Am I missing something? Is my setup wrong somehow? Something about Maven >> layout maybe? >> > > What's "wrong" is to include all that server-side code to the DevMode's > classpath; it has to do with both the org.codehaus.mojo:gwt-maven-plugin > and your Maven layout. > > I'd suggest: > > - Split your client module to separate client-side code that's > compiled to JS, and assembling the WAR with that compiled JS and the > server > module JAR; and move the XML Spring configuration to the new war module. > The client module could then exclude all transitive dependencies of the > server module (it only needs the SampleService and SampleServiceLocator); > alternatively, maybe the server module could depend on Spring with > scope=provided, and the new war module would add the Spring dependencies > back with scope=compile or scope=runtime to get them into the WAR. You > could maybe also split the server module to separate the classes that the > client module depends on (the SampleServiceLocator only depends on > Spring's > WebApplicationContext and WebApplicationContextUtils, which could be > dependencies with scope=provided in the "shared" module). The thing is, we > don't want the client module to depend on anything Spring-related > (particularly the XML configuration resources). > - That should be enough (hopefully), but I'd also migrate to the > net.ltgt.gwt.maven:gwt-maven-plugin to make launching DevMode easier, and > I > would actually move to using the tomcat7-maven-plugin (too bad there's not > a more recent version) and use CodeServer instead of DevMode. > > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
