Re: GWT SuperDev mode issue after migrating from 2.7.0 to 2.8.1 with application that uses Spring Framework

[Andrei Anishchenko]

Thank you, that helped a lot!

On Monday, July 17, 2017 at 5:49:23 PM UTC+3, Thomas Broyer wrote:
>
> 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
>>>  
>>> 
>>>  
>>> 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 
>>> .
>>>  
>>> If these 
>>> 
>>>  
>>> 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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT SuperDev mode issue after migrating from 2.7.0 to 2.8.1 with application that uses Spring Framework

[Thomas Broyer]

On Monday, July 17, 2017 at 5:07:37 PM UTC+2, Ignacio Baca Moreno-Torres 
wrote:
>
> But this is not a multimodule project (means this is not a tbroyer 
> archetype multimodule project), you need a shared lib, and the client 
> should Not depend on the server, but if you continue with this layout at 
> least explicitly exclude non required libs from the server dependency in 
> the client pom, as anything related with spring.
>

Note that I believe the real culprit here is/was 
server/src/main/resources/applicationContext.xml, so excluding transitive 
dependencies to Spring would not be enough.
(I didn't test it though, so cannot confirm nor deny)

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT SuperDev mode issue after migrating from 2.7.0 to 2.8.1 with application that uses Spring Framework

[Ignacio Baca Moreno-Torres]

But this is not a multimodule project (means this is not a tbroyer
archetype multimodule project), you need a shared lib, and the client
should Not depend on the server, but if you continue with this layout at
least explicitly exclude non required libs from the server dependency in
the client pom, as anything related with spring.

El lun., 17 jul. 2017 11:05, Andrei Anishchenko 
escribió:

> 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
> 
> 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. If these
> 
> 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?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT SuperDev mode issue after migrating from 2.7.0 to 2.8.1 with application that uses Spring Framework

[Thomas Broyer]

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
>>  
>> 
>>  
>> 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 
>> .
>>  
>> If these 
>> 
>>  
>> 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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT SuperDev mode issue after migrating from 2.7.0 to 2.8.1 with application that uses Spring Framework

[Thomas Broyer]

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
>  
> 
>  
> 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 
> .
>  
> If these 
> 
>  
> 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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.