On startup of my application i would like to make an rpc call form the client to the server. The call would result in the server creating a Properties object from a .properties file and passing it back to the client. However this does not seem to be possible as when i do this i get an error "No source code is available for type java.util.Properties; did you forget to inherit a required module?". I then tried to use a GWT Dictionary instead but doing so resulted in a error because a dictionary object is not serializable. Any ideas of how to fix either of the above 2 errors or of another way of doing this.
You cannot pass java.util.Properties back to client in RPC. The list of java classes in GWT that are emulated is listed http://www.gwtproject.org/doc/latest/RefJreEmulation.html
Also you should process the properties file into a model/pojo class in serializable java class and pass it back in RPC. You can use JSON object to do the same.
In any case you should process the properties file on server side into a format that is acceptable to GWT via JSON or RequestFactory or RPC.
Related
When using gwt-maven-plugin's generateAsync, is it possible to apply an annotation (or something) to an individual gwt-rpc service so that the corresponding async isn't auto-generated and can be written manually?
Alternatively, is there an annotation (or something) that makes the generated asyncs have the "Request" return type?
From the gwt-maven-plugin's documentation you need to adjust the servicePattern configuration property, or you can ask it to always generate methods returning Request.
Or, even better, don't use this goal!
(or only call it manually once in a while and copy the generated classes to your sources)
The GWT Generators will never create a class if one already exists with that name. This means you can ask GWT to compile and generate the code, then copy the classes into your sources and customize them, and later compiler runs will not attempt to generate sources.
This may have other side effects - if the proxy, typeserializer, or fieldserializer is prevented from being generated, then the RPC generators may assume that other dependencies have also all been correctly generated, so you may find yourself missing classes if you don't also copy those other classes. Likewise, of course any changes that require your serializers being modified or rebuilt will have to be done manually, such as changing a serializable type, or modifying a RPC method.
Your async interface can always declare a return type of Request or RequestBuilder instead of void. If you declare RequestBuilder, then the request will not be sent automatically, and you must call send(), whereas a Request returned means that the request has been sent.
I have a GWT project in Eclipse that throws a com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException when using hosted mode because the code server RPC file hashcode does not match the server RPC file hashcode.
I've tracked this down to a couple classes that implement com.extjs.gxt.ui.client.data.BeanModelTag. These classes appear to be included in the code server generated RPC file incorrectly. Additionally, the class names appear mangled.
For example, instead of com.acme.beans.MyBean the class is referenced as com.acme.beans.BeanModel_com_acme_beans_MyBean.
I suspect this has something to do with the class path for my debug target incorrectly including some jar, src dir, or other project incorrectly, but I don't have good feel for how to debug this further.
GXT 2 (current is 3, 4 should beta soonish) had a feature where it could generate BaseModelData types based on a java bean or pojo, allowing for reflection-like features that GXT 2 used to render templates and grid cells (GXT 3 has compile-time features that work out that property access instead). The BeanModels are not meant to be sent over the wire - instead, you should be sending your original MyBean over the wire.
This generated BeanModel instance is designed to wrap the original MyBean, and is only available to the client code. To pass back to the server again, unwrap the bean - use getBean() to get the underlying pojo.
I'd like to know if it is possible to use the serializer of GWT. When using the rpc-mechnism of GWT, GWT serializes the objects on the client and deserializes the objects on the server. For this mechanism you have to use special servlets (RemoteServiceServlet) of GWT. But i want to use the normal HttpServlets and therefore i have to serialize and deserialize the objects by myself.
All the code you need to look at is in the RemoteServiceServlet.java. Focus on the processCall method.
The RPC.decodeRequest(payload, ...) will give you a RPCRequest object which includes the method to be called and the deserialized parameters.
To encode the response focus on RPC.invokeAndEncodeResponse() and RPC.encodeResponseForSuccess() methods.
[EDITED]
In client-side it's worth to take a look to the proxy classes generated by the RPC generator, concretely the YourService_Proxy.java file. Generated files are left somewhere in your project's folder structure after compiling a project (you can indicate this folder with the -gen though).
The interesting code is in in the RemoteServiceProxy, looking at the createStreamWritter method, you can see how to serialize your objects. In the createStreamReader you can see how to deserialize a message from the server.
See gwt-byte-serializer
SerializerInt ser = new Serializer();
ser.writeValue("test");
ser.writeValue(new int[]{5,1,6});
String buffer = ser.getBuffer();
SerializerInt des = new Serializer(buffer);
des.readString()
des.readIntegerArr()
Is there an easy way to use SerializationStreamWriter for custom purposes without writing an own generator?
(for example html5 storage)
The javadoc of GWT tells very little.
We are writing an implementation for our current project, which does exactly what you want do: serialize an custom object into string and save it into the localstorage, deserialize the string into an object...
So, for me, it is possbile, to use SerializationStreamWriter for serialization, and use SerializationStreamReader for deserialization in CLIENT SIDE.
To realize this,
you don't need a generator for SerializationStreamWriter/SerializationStreamReader, but a generator for TypeSerializer (which implements com.google.gwt.user.client.rpc.impl.SerializerBase). And this is quiet simple, take a look at com.google.gwt.user.rebind.rpc.TypeSerializerCreator, and use it in your generator. OR, if all your custom objects are referenced in one RPC service, you can just use the generated rpc service's TypeSerializer.
And you must write a proper implementation of SerializationStreamWriter OR SerializationStreamReader. Because there has two serialized string formats(request used format and response used format):
IN GWT, you have
ClientSerializationStreamWriter, ClientSerializationStreamReader for client side serialization/deserialization;
ServerSerializationStreamWriter, ServerSerializationStreamReader for server side serialization/deserialization;
Client SerializationStream Writer will serialize the object into FORMAT_1, and only Server SerializationStream Reader can read it (deserialize it into object).
Server SerializationStream Writer will serialize the object into FORMAT_2, and only Client SerializationStream Reader can read it (deserialize it into object).
so what you need to do, if you want to use ClientSerializationStreamWriter to serialize your object, then write a similar implementation of ServerSerializationStreamReader for client side. Or if you want to use ClientSerializationStreamWriter to deserialize the string, then write a similar implementation of ServerSerializationStreamWriter in client side. This is not difficult, because the difference between FORMAT_1 and FORMAT_2 is just the order.
No.
Because the GWT-RPC serialization is asymmetric, it cannot be used for local storage: the server understands what the client sent, the client understands what the server sent, but they won't understand what they themselves wrote.
I have encountered following problem.
Currently I'm working with colleague on GWT project.
We are using RPC async service. We often need to send and receive state object which is a HashMap.
We have bunch of service methods which are always have state as parameter and as a return type:
HashMap<String, Serializable> fillAndGetUI(HashMap<String, Serializable> state) throws ProjectServiceException;
I'm telling not to use this because we have Serializable interface in method declaration which is not good for RPC and GWT compilation.
But: HashMap is useful while we can use hotswap instead of restarting server each time (it's enough to write method put and get).
My suggestion was to use POJO, but we can loose hotswap abliliy which is critical.
What is the solution to not use HashMap in declarations and have Hotswap ability in the same time ? Can RequestFactory solve this issue? (We are using GWT 2.1. version change is not an option)
The easiest solution use plain old RequestBuilder, JSON and Overlay Types. RequestFactory will not help you