[gwt-contrib] Re: SDM + gin + generated GinModule not working well together

[confile]

I can confirm that this problem occurs to me too.

Michael

Am Sonntag, 16. November 2014 21:56:20 UTC+1 schrieb Nicolas Morel:
>
> Hi, 
>
> I'm currently testing GWT 2.7.0-rc1 and one of my project using GWTP 
> 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 
> . The "normal" compilation 
> works but not the incremental compile from SDM.
>
> I made a simple example available here 
> .
>
> From what I saw, the RestGinModule that gin is trying to load is generated 
> by a GWT generator (VelocityGenerator 
> 
> .generateRestGinModule()) and passed to gin through the property
>  "gin.ginjector.modules". 
> It seems unconventional but was working before.
> Any ideas what is going on please ?
>
>
>
>

-- 
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/76a1f152-f848-4802-b3f0-4da086789cfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: 2.7.0 RC1 SDM not working when using java.util.List - Example attached

['John Stalcup' via GWT Contributors]

A "fix" for this is now committed. Which means this code snippet will now
be rejected all the time.

To accomplish the same thing you need to execute the .size() function
dispatch (or really any function dispatch on a List instance since you've
used the List interface on a JSO type) inside of a *Java* not inside of a
JSNI function. This is relatively straight forward if you make a static
Java function that takes a List instance and calls size() on it, and you
can call this static Java function inside of your JSNI.


On Wed Nov 12 2014 at 4:05:26 PM John Stalcup  wrote:

> It's more like, 50% of the time.
>
> Here's what's going on:
>
> It's currently illegal to call foo.blah() in JSNI if the variable foo is
> either a JSO type or interface that is implemented by some JSO type.
>
> The error you're seeing is JsniReferenceResolver enforcing this
> requirement, the weird part is that it should enforce it all the time but
> it's only enforcing it 50% of the time.
>
> The reason this is occurring is that depending on the order that JDT
> processes types we may or may not yet have collected the knowledge to know
> that the java.util.List interface is used on a JSO before
> JsniReferenceResolver performns its check.
>
> We need to move the correctness check to some later stage, late enough
> that "is JSO" checks will always be accurate.
>
> In the 50% of compiles that are succeeding for you right now you're
> actually vulnerable to runtime errors because it's outputting code that
> attempts to call the "size()" function on the prototype of the "list"
> parameter (and that will fail if the instance that is passed in happens to
> be a JsArrayListWrapper).
>
>
> On Wed Nov 12 2014 at 1:27:42 PM John Stalcup  wrote:
>
>> I'm able to repro this both with -noincremental and -incremental, but
>> only randomly (seems about 30% of the time).
>>
>> Still looking into it.
>> On Wed Nov 12 2014 at 8:24:43 AM Thomas Broyer 
>> wrote:
>>
>>> [+cc stalcup@]
>>>
>>> This might be because of incremental compilation: when
>>> JsArrayListWrapper is in another module, that module is "precompiled", so
>>> the compiler knows about the type. When it's in the same module, because
>>> it's the module being compiled, it can be pruned (unused) and as
>>> consequence doesn't interfere with the JSNI checks.
>>>
>>> The workaround would be to call a static method passing the List as
>>> argument, and call the size() method in that static method, in Java-land,
>>> outside of JSNI.
>>>
>>>
>>> On Wednesday, November 12, 2014 1:39:55 PM UTC+1, Jan Thewes wrote:

 Hello guys,

 we're currently running in problems related to the SDM in GWT 2.7.
 We've attached two examples.
 JsListWrapperWorking is an example project where everything is working
 fine. It is CODE IDENTICAL to JsListWrapperNotWorking.
 In the latter one we've moved the source for the two classes
 JsArrayListWrapper and JsArrayWrapper to another module.
 No source code has been touched.

 When starting SDM for JsListWrapperWorking everything is working fine.
 When starting SDM for JsListWrapperNotWorking we get following
 exception:

 [ERROR] Errors in 'file:~/JsListWrapperNotWorking/src/
 de/gad/list/client/JsListWrapperNotWorking.java'

 [ERROR] Line 19: Referencing interface method 'java.util.List.size()':
 implemented by 'de.gad.list.client.myListImpl.JsArrayListWrapper';
 references to instance methods in overlay types are illegal; use a stronger
 type or a Java trampoline method


 If you need any further information I'll provide them as soon as
 possible!


 Cheers,

 Jan

>>>

-- 
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/CAFw3gJ91Eqd-Ovxcy9EUADsm-BStJO9hkNvKd1t_oMyBTrHv2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: SDM + gin + generated GinModule not working well together

[Christopher Viel]

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:*











*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  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 
> . The "normal" compilation 
> works but not the incremental compile from SDM.
>
> I made a simple example available here 
> .
>
> From what I saw, the RestGinModule that gin is trying to load is generated 
> by a GWT generator (VelocityGenerator 
> 
> .generateRestGinModule()) and passed to gin through the property
>  "gin.ginjector.modules". 
> It seems unconventional but was working before.
> Any ideas what is going on please ?
>
>
>
>

-- 
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/57be9c00-e1f2-4c99-ad20-40c0c86943aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.