Re: [gwt-contrib] Re: SDM + gin + generated GinModule not working well together
Thanks for the patch, it works on the hello world project I made.
However, it is still not enough for the bigger project I'm working on. I'll
try to investigate and determine what's going on or reproduce it via a more
complex example.
Le vendredi 21 novembre 2014 00:04:03 UTC+1, John Stalcup a écrit :
Though we do not make a promise to process GWT.create() of entry point
types before any other GWT.create() calls, it was easy to restore this
behavior in incremental, so I went ahead and did it (
https://gwt-review.googlesource.com/#/c/10410/).
You should probably find a way not to depend on this in the future, as it
is not promised and may change again.
On Mon Nov 17 2014 at 2:07:02 PM Christopher Viel viel.chr...@gmail.com
javascript: wrote:
Hi,
I'm gonna add some more background here.
The generator generates a bunch of file and binds the interfaces using
GIN. I would't say this is strictly necessary, but it brings the advantages
of DI to the generated code. So we have an Entry Point that is an interface
and a rebind rule. UserAgentAsserter uses a similar technique. What we also
do is generate a Ginjector interface and put a
*GWT.create(GeneratedGinjector.class)* call inside the generated entry
point. That way GIN's generator is called after and everything should be
resolvable. The generated ginjector is setup to look at a specific property
to load additional gin modules. Here it happens that one of them is also
generated. So all of that actually work with 2.7.
What no longer works is if the entry point and the ginjector are no
longer generated. If there is a GWT.create() call that resolves to a
Ginjector from an explicit entry point, it fails. I'm not sure I'm being
very clear here so here's an example:
*MyModule.gwt.xml:*
module
entry-point class=com.project.EntryPointToGenerate/
entry-point class=com.project.ExplicitEntryPoint/
extend-configuration-property name=gin.ginjector.modules
value=com.project.GeneratedGinModule/
generate-with class=com.project.EntryPointGenerator
when-type-is class=com.project.EntryPointToGenerate/
/generate-with
/module
*EntryPointToGenerate:*
public interface EntryPointToGenerate extends EntryPoint {}
*EntryPointGenerator*: Generates *com.project.GeneratedGinModule* and an
implementation of *EntryPointToGenerate*
*ExplicitEntryPoint*:
public class ExplicitEntryPoint implements EntryPoint {
private static final ExplicitGinjector GINJECTOR = GWT.create(
ExplicitGinjector.class);
@Override
public void onModuleLoad() {}
}
*ExplicitGinjector:*
@GinModules( value = ExplicitGinModule.class, properties =
gin.ginjector.modules )
public interface ExplicitGinjector extends Ginjector {
/* snip */
}
With this code in a regular compilation, EntryPointToGenerate is
generated before ExplicitEntryPoint is traversed. With incremental
compilation, ExplicitEntryPoint is traversed (and incidentally GINs
generator is called) before EntryPointGenerator is called. I would expect
the first entry point to be traversed at first, even if it means calling a
generator.
On Sunday, November 16, 2014 3:56:20 PM UTC-5, Nicolas Morel wrote:
Hi,
I'm currently testing GWT 2.7.0-rc1 and one of my project using GWTP
Rest-Dispatch https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch is
not working under SDM.
The compilation fails with this error :
[ERROR] Unable to load gin module type
[com.gwtplatform.dispatch.rest.client.RestGinModule], maybe you haven't
compiled your client java sources?
java.lang.ClassNotFoundException: com$gwtplatform$dispatch$rest$
client$RestGinModule
at com.google.gwt.inject.rebind.GinBridgeClassLoader.findClass(
GinBridgeClassLoader.java:150)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at com.google.gwt.inject.rebind.GinBridgeClassLoader.loadClass(
GinBridgeClassLoader.java:108)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at com.google.gwt.inject.rebind.GinjectorGenerator.loadClass(
GinjectorGenerator.java:223)
at com.google.gwt.inject.rebind.GinjectorGenerator.
getPropertyModuleClasses(GinjectorGenerator.java:137)
at com.google.gwt.inject.rebind.GinjectorGenerator.getModuleClasses(
GinjectorGenerator.java:116)
at com.google.gwt.inject.rebind.GinjectorGenerator.generate(
GinjectorGenerator.java:72)
at com.google.gwt.core.ext.IncrementalGenerator.
generateNonIncrementally(IncrementalGenerator.java:40)
The full stack trace is available in attachment.
The problem has been reported to the GWTP team here
https://github.com/ArcBees/GWTP/issues/614. The normal compilation
works but not the incremental compile from SDM.
I made a simple example available here
https://github.com/nmorel/hello-gwt-rest-dispatch.
From what I saw, the RestGinModule that gin is trying
[gwt-contrib] Re: GWT 2.7 Scheduler works different on mobile and desktop in SDM
Timer and Scheduler.scheduleDeffered would not be expected to be equivalent. They have two different semantics. Scheduler.scheduleDeffered - runs after the browser event loop returns. new Timer().schedule(1000) - runs 1000 ms after being scheduled. You can not expect Scheduler.scheduleDeffered to give consistent results across platform. Scheduler.scheduleFixedDelay would be more equivalent to Timer.schedule On Tuesday, November 25, 2014 6:47:04 AM UTC-7, confile wrote: It seems that the Scheduler works different on mobile and desktop when using SDM. I created a demo project ( https://github.com/confile/GWT-2.7-Scheduler-Test) to show the problem. This is a demo app to test how the GWT Scheduler works different on mobile and on desktop in Super Dev Mode. I printed the height of a HTMLPanel for three different cases. 1. right after the DOM elements are inserted into the page (GWTP onReveal()) 2. right after the DOM elements are inserted into the page and Scheduler with a deferred command is executed 3. right after the DOM elements are inserted into the page and a Timer after 1000mx is fired Here is the difference in the console output: Output on Desktop - height before Timer and Scheduler: 0 - height after Scheduler: 652 - height after Timer: 652 Output on Mobile (iPhone 5, iOS 7.1.1) - height before Timer and Scheduler: 0 - height after Scheduler: 425 - height after Timer: 817 -- 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/15602de8-3472-4b1d-a26c-492296b564cd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: GWT 2.7 Scheduler works different on mobile and desktop in SDM
It is clear that Timer and Scheduler are different. My concern is that Scheduler.scheduleDeffered behaves so differnent on different platforms. What is the best way to handle this? Am Mittwoch, 26. November 2014 16:11:01 UTC+1 schrieb Jonathon Lamon: Timer and Scheduler.scheduleDeffered would not be expected to be equivalent. They have two different semantics. Scheduler.scheduleDeffered - runs after the browser event loop returns. new Timer().schedule(1000) - runs 1000 ms after being scheduled. You can not expect Scheduler.scheduleDeffered to give consistent results across platform. Scheduler.scheduleFixedDelay would be more equivalent to Timer.schedule On Tuesday, November 25, 2014 6:47:04 AM UTC-7, confile wrote: It seems that the Scheduler works different on mobile and desktop when using SDM. I created a demo project ( https://github.com/confile/GWT-2.7-Scheduler-Test) to show the problem. This is a demo app to test how the GWT Scheduler works different on mobile and on desktop in Super Dev Mode. I printed the height of a HTMLPanel for three different cases. 1. right after the DOM elements are inserted into the page (GWTP onReveal()) 2. right after the DOM elements are inserted into the page and Scheduler with a deferred command is executed 3. right after the DOM elements are inserted into the page and a Timer after 1000mx is fired Here is the difference in the console output: Output on Desktop - height before Timer and Scheduler: 0 - height after Scheduler: 652 - height after Timer: 652 Output on Mobile (iPhone 5, iOS 7.1.1) - height before Timer and Scheduler: 0 - height after Scheduler: 425 - height after Timer: 817 -- 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/93f92371-4bfe-42c3-a1c8-44390e3fb543%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 Scheduler works different on mobile and desktop in SDM
@confile it is not possible to run your example because it is missing dependencies. From reading the code, the problem you are having is probably not caused by the Scheduler but by the time taken to resolve test.jpg. After modifying an element it is not necessary to pause before calling getOffsetHeight(). The call itself will force a redraw and the value will not change over time unless the element itself changes. In this case the height of the image element is changing as test.jpg downloads, this is why your output is inconsistent. On Wed, Nov 26, 2014 at 6:45 PM, confile michael.gorsk...@googlemail.com wrote: It is clear that Timer and Scheduler are different. My concern is that Scheduler.scheduleDeffered behaves so differnent on different platforms. What is the best way to handle this? Am Mittwoch, 26. November 2014 16:11:01 UTC+1 schrieb Jonathon Lamon: Timer and Scheduler.scheduleDeffered would not be expected to be equivalent. They have two different semantics. Scheduler.scheduleDeffered - runs after the browser event loop returns. new Timer().schedule(1000) - runs 1000 ms after being scheduled. You can not expect Scheduler.scheduleDeffered to give consistent results across platform. Scheduler.scheduleFixedDelay would be more equivalent to Timer.schedule On Tuesday, November 25, 2014 6:47:04 AM UTC-7, confile wrote: It seems that the Scheduler works different on mobile and desktop when using SDM. I created a demo project (https://github.com/confile/ GWT-2.7-Scheduler-Test) to show the problem. This is a demo app to test how the GWT Scheduler works different on mobile and on desktop in Super Dev Mode. I printed the height of a HTMLPanel for three different cases. 1. right after the DOM elements are inserted into the page (GWTP onReveal()) 2. right after the DOM elements are inserted into the page and Scheduler with a deferred command is executed 3. right after the DOM elements are inserted into the page and a Timer after 1000mx is fired Here is the difference in the console output: Output on Desktop - height before Timer and Scheduler: 0 - height after Scheduler: 652 - height after Timer: 652 Output on Mobile (iPhone 5, iOS 7.1.1) - height before Timer and Scheduler: 0 - height after Scheduler: 425 - height after Timer: 817 -- 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/93f92371-4bfe-42c3-a1c8-44390e3fb543%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/93f92371-4bfe-42c3-a1c8-44390e3fb543%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/CAEqaEVjVa1_rOzCGtJ5ihsaLY5RwacoNxPvdp04crHGJxi2Q-g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 Scheduler works different on mobile and desktop in SDM
Richard what do you suggest to solve this problem? Am Mittwoch, 26. November 2014 19:01:02 UTC+1 schrieb Richard Wallis: @confile it is not possible to run your example because it is missing dependencies. From reading the code, the problem you are having is probably not caused by the Scheduler but by the time taken to resolve test.jpg. After modifying an element it is not necessary to pause before calling getOffsetHeight(). The call itself will force a redraw and the value will not change over time unless the element itself changes. In this case the height of the image element is changing as test.jpg downloads, this is why your output is inconsistent. On Wed, Nov 26, 2014 at 6:45 PM, confile michael@googlemail.com javascript: wrote: It is clear that Timer and Scheduler are different. My concern is that Scheduler.scheduleDeffered behaves so differnent on different platforms. What is the best way to handle this? Am Mittwoch, 26. November 2014 16:11:01 UTC+1 schrieb Jonathon Lamon: Timer and Scheduler.scheduleDeffered would not be expected to be equivalent. They have two different semantics. Scheduler.scheduleDeffered - runs after the browser event loop returns. new Timer().schedule(1000) - runs 1000 ms after being scheduled. You can not expect Scheduler.scheduleDeffered to give consistent results across platform. Scheduler.scheduleFixedDelay would be more equivalent to Timer.schedule On Tuesday, November 25, 2014 6:47:04 AM UTC-7, confile wrote: It seems that the Scheduler works different on mobile and desktop when using SDM. I created a demo project (https://github.com/confile/ GWT-2.7-Scheduler-Test) to show the problem. This is a demo app to test how the GWT Scheduler works different on mobile and on desktop in Super Dev Mode. I printed the height of a HTMLPanel for three different cases. 1. right after the DOM elements are inserted into the page (GWTP onReveal()) 2. right after the DOM elements are inserted into the page and Scheduler with a deferred command is executed 3. right after the DOM elements are inserted into the page and a Timer after 1000mx is fired Here is the difference in the console output: Output on Desktop - height before Timer and Scheduler: 0 - height after Scheduler: 652 - height after Timer: 652 Output on Mobile (iPhone 5, iOS 7.1.1) - height before Timer and Scheduler: 0 - height after Scheduler: 425 - height after Timer: 817 -- 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 javascript:. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/93f92371-4bfe-42c3-a1c8-44390e3fb543%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/93f92371-4bfe-42c3-a1c8-44390e3fb543%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/8bb121c7-2372-4419-86e7-993d9e992cd3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: GWT 2.7 Scheduler works different on mobile and desktop in SDM
Guessing but you can probably use image addLoadHandler() to wait for the image to load before checking the height. A more complex alternative is to download the image using a getRequest and then transform it into a base64 dataUrl and use that as the src for your image. On Wed, Nov 26, 2014 at 8:31 PM, confile michael.gorsk...@googlemail.com wrote: Richard what do you suggest to solve this problem? Am Mittwoch, 26. November 2014 19:01:02 UTC+1 schrieb Richard Wallis: @confile it is not possible to run your example because it is missing dependencies. From reading the code, the problem you are having is probably not caused by the Scheduler but by the time taken to resolve test.jpg. After modifying an element it is not necessary to pause before calling getOffsetHeight(). The call itself will force a redraw and the value will not change over time unless the element itself changes. In this case the height of the image element is changing as test.jpg downloads, this is why your output is inconsistent. On Wed, Nov 26, 2014 at 6:45 PM, confile michael@googlemail.com wrote: It is clear that Timer and Scheduler are different. My concern is that Scheduler.scheduleDeffered behaves so differnent on different platforms. What is the best way to handle this? Am Mittwoch, 26. November 2014 16:11:01 UTC+1 schrieb Jonathon Lamon: Timer and Scheduler.scheduleDeffered would not be expected to be equivalent. They have two different semantics. Scheduler.scheduleDeffered - runs after the browser event loop returns. new Timer().schedule(1000) - runs 1000 ms after being scheduled. You can not expect Scheduler.scheduleDeffered to give consistent results across platform. Scheduler.scheduleFixedDelay would be more equivalent to Timer.schedule On Tuesday, November 25, 2014 6:47:04 AM UTC-7, confile wrote: It seems that the Scheduler works different on mobile and desktop when using SDM. I created a demo project (https://github.com/confile/GW T-2.7-Scheduler-Test) to show the problem. This is a demo app to test how the GWT Scheduler works different on mobile and on desktop in Super Dev Mode. I printed the height of a HTMLPanel for three different cases. 1. right after the DOM elements are inserted into the page (GWTP onReveal()) 2. right after the DOM elements are inserted into the page and Scheduler with a deferred command is executed 3. right after the DOM elements are inserted into the page and a Timer after 1000mx is fired Here is the difference in the console output: Output on Desktop - height before Timer and Scheduler: 0 - height after Scheduler: 652 - height after Timer: 652 Output on Mobile (iPhone 5, iOS 7.1.1) - height before Timer and Scheduler: 0 - height after Scheduler: 425 - height after Timer: 817 -- 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/93f92371-4bfe- 42c3-a1c8-44390e3fb543%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/93f92371-4bfe-42c3-a1c8-44390e3fb543%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/8bb121c7-2372-4419-86e7-993d9e992cd3%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/8bb121c7-2372-4419-86e7-993d9e992cd3%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/CAEqaEVj-ouJ3drkPPHMC_VS_bwRzNegzF8niv3kFUz0w_55%2BnA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
