RequestFactory - Error: The requested type is not default-instantiable

[zorro]

Is there a way to find out WHICH TYPE other then scanning my large codebase?

[Thomas Broyer]

On Friday, June 8, 2012 12:59:57 AM UTC+2, zorro wrote:

Is there a way to find out WHICH TYPE other then scanning my large codebase?

Isn't ValidationTool giving you warnings?

You can also simply put a breakpoing into ReflectiveServiceLayer where this error is reported and look at the value of the 'clazz' argument.

[zorro]

There is no such

02:47:55.811 [ERROR] [roamtopix] Uncaught exception escaped

com.google.web.bindery.event.shared.UmbrellaException: One or more exceptions caught, see full set in UmbrellaException#getCauses

    at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.fail(AbstractRequestContext.java:727)

    at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext$StandardPayloadDialect.processPayload(AbstractRequestContext.java:331)

    at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext$5.onTransportSuccess(AbstractRequestContext.java:1108)

    at com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport$1.onResponseReceived(DefaultRequestTransport.java:136)

    at com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:287)

    at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:395)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)

    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)

    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)

    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:337)

    at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:218)

    at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)

    at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:561)

    at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:269)

    at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)

    at com.google.gwt.core.client.impl.Impl.apply(Impl.java)

    at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:213)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)

    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)

    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)

    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:292)

    at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:546)

    at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:363)

    at java.lang.Thread.run(Thread.java:662)

Caused by: java.lang.RuntimeException: Server Error: The requested type is not default-instantiable

    at com.google.web.bindery.requestfactory.shared.Receiver.onFailure(Receiver.java:44)

    at com.google.web.bindery.requestfactory.shared.impl.AbstractRequest.onFail(AbstractRequest.java:118)

    at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext.fail(AbstractRequestContext.java:707)

    at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext$StandardPayloadDialect.processPayload(AbstractRequestContext.java:331)

    at com.google.web.bindery.requestfactory.shared.impl.AbstractRequestContext$5.onTransportSuccess(AbstractRequestContext.java:1108)

    at com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport$1.onResponseReceived(DefaultRequestTransport.java:136)

    at com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:287)

    at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:395)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)

    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)

    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)

    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessagesWhileWaitingForReturn(BrowserChannelServer.java:337)

    at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:218)

    at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)

    at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:561)

    at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:269)

    at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)

    at com.google.gwt.core.client.impl.Impl.apply(Impl.java)

    at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:213)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at java.lang.reflect.Method.invoke(Method.java:597)

    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:103)

    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)

    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)

    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:292)

    at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:546)

    at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:363)

    at java.lang.Thread.run(Thread.java:662)

Dne pátek, 8. června 2012 10:00:41 UTC+2 Thomas Broyer napsal(a):

[zorro]

Compiler gives me errors related to JSNI. Nothing more.

>>Isn't ValidationTool giving you warnings? 

I have:

<init-param>

<param-name>symbolMapsDirectory</param-name>

<!-- You'll need to compile with -extras and move the symbolMaps directory 

to this location if you want stack trace deobfuscation to work -->

<param-value>WEB-INF/classes/symbolMaps/</param-value>

</init-param>

And I am compiling with -extra WEB-INF/classes/symbolMaps

Q: Does this mean that errors will send stack traces ? 

Q: Does obfuscation apply to debugging mode as well?

--------------

Why the aforementioned error message "The requested type is not default-instantiable" does not include concrete type info?

It would speed up development.

Dne pátek, 8. června 2012 10:00:41 UTC+2 Thomas Broyer napsal(a):

[zorro]

That breakpoint really helped. (It is trying to instantiate an interface - due to some refactoring)

Dne pátek, 8. června 2012 10:00:41 UTC+2 Thomas Broyer napsal(a):

[Thomas Broyer]

On Friday, June 8, 2012 2:14:27 PM UTC+2, zorro wrote:

Why the aforementioned error message "The requested type is not default-instantiable" does not include concrete type info?

It would speed up development.

I agree (kind of), though in theory this should have been caught up by the ValidationTool at compile time (and really, it should: http://code.google.com/p/google-web-toolkit/source/browse/tags/2.4.0/user/src/com/google/web/bindery/requestfactory/apt/DomainChecker.java#239 )

In the mean time, set a breakpoint in ReflectiveServiceLayer and look at the value of the clazz argument:

http://code.google.com/p/google-web-toolkit/source/browse/tags/2.4.0/user/src/com/google/web/bindery/requestfactory/server/ReflectiveServiceLayer.java#84

[zorro]

Well, I have the requestFactory-apt set as annotation processor. But maybe problem is that the type that I wanted to create on server is an interface! And this is not covered by compiler at all! 

Can I say to this magical RequestFactory stuff say what type to instantiate on the server, if interface is allowed (apparently) in the ProxyFor annotation? 

I woudl really appreciate that because I am using interfaces to get rid of tuns of necessary copying among proxy objects and real gwt objects. My original intention was to use gwt so I can move functionality execution easily from server to client. Therefore RF proxies in my case should be the same as the domain objects. Therefore interfaces.

GWT RPC does not work for me for several reasons. One of them is that I can not obfuscate errors in the RPC.class everything is static and final. I can not hook in.

Dne pátek, 8. června 2012 14:29:46 UTC+2 Thomas Broyer napsal(a):

[Thomas Broyer]

On Friday, June 8, 2012 4:14:44 PM UTC+2, zorro wrote:

Well, I have the requestFactory-apt set as annotation processor. But maybe problem is that the type that I wanted to create on server is an interface! And this is not covered by compiler at all!

Would you mind filing an issue on the tracker?

(DomainChecker should check that the type is instantiable, i.e. neither an interface or an abstract class –or an enum!)

 

Can I say to this magical RequestFactory stuff say what type to instantiate on the server, if interface is allowed (apparently) in the ProxyFor annotation?

You can use a Locator (on server-side, responsible for "instantiating your interface") and link to it from the ProxyFor annotation.

https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory#locators

 

I woudl really appreciate that because I am using interfaces to get rid of tuns of necessary copying among proxy objects and real gwt objects. My original intention was to use gwt so I can move functionality execution easily from server to client. Therefore RF proxies in my case should be the same as the domain objects. Therefore interfaces.

In your case, I'd make sure to reference the real domain object (that implements the same interface that the proxy extends).

I suppose that's what you were willing to do, but somehow forgot to change the ProxyFor value during the refactoring, and the bug in ValidationTool didn't tell you you were wrong, right?

[zorro]

Dne pátek, 8. června 2012 16:48:47 UTC+2 Thomas Broyer napsal(a):

On Friday, June 8, 2012 4:14:44 PM UTC+2, zorro wrote:

Well, I have the requestFactory-apt set as annotation processor. But maybe problem is that the type that I wanted to create on server is an interface! And this is not covered by compiler at all!

Would you mind filing an issue on the tracker?

(DomainChecker should check that the type is instantiable, i.e. neither an interface or an abstract class –or an enum!)

Actually, it would make sense that type is an Interface if used together with "locator". What do you think?

In my case I am using valueproxies only, since I am only sending "packages" of data that do not "live" on themselves on the server.

 

Can I say to this magical RequestFactory stuff say what type to instantiate on the server, if interface is allowed (apparently) in the ProxyFor annotation?

You can use a Locator (on server-side, responsible for "instantiating your interface") and link to it from the ProxyFor annotation.

https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory#locators

 

I woudl really appreciate that because I am using interfaces to get rid of tuns of necessary copying among proxy objects and real gwt objects. My original intention was to use gwt so I can move functionality execution easily from server to client. Therefore RF proxies in my case should be the same as the domain objects. Therefore interfaces.

In your case, I'd make sure to reference the real domain object (that implements the same interface that the proxy extends).

I suppose that's what you were willing to do, but somehow forgot to change the ProxyFor value during the refactoring, and the bug in ValidationTool didn't tell you you were wrong, right?

You are absolutely right here:- But I need to reference interfaces, cause this allows me to make types of proxies and my JSO objects more adjacent and thus save me some code. E.G. At least I can save some handcrated:- copying like this:

List<SyncItem> toServerItems = syncPushToServer.getItems();

        serverPush.setItems(new ArrayList<SyncItemProxy>(toServerItems)); 

I have 

1.     public class SyncItem implements Serializable, ISyncItem {

    @ProxyForName(value = "com.roamtopix.shared.SyncItem")

    public interface SyncItemProxy extends ValueProxy {

       ..a lot of setters/getters

    }

2.  @ProxyFor(IWindow.class) 

   public interface WindowProxy extends ValueProxy, IWindow {

       ..NOTING, everythig is on IWindow

   }

Difference between 1 and 2 is in what direction I need to "copy" objects on the client (from proxy to gwt-normal or JSO to gwt-normal or to gwt-proxy)

And can go with it. However I need interfaces to work in @ProxyFor annot. In my case IWindow is an interface. If I find out that this does not work wint EntityProxy I fill in that bug. 

 

[zorro]

http://code.google.com/p/google-web-toolkit/issues/detail?id=7414 

Dne pátek, 8. června 2012 16:48:47 UTC+2 Thomas Broyer napsal(a):