FAQ - Server
- Why doesn’t GWT provide a synchronous server connection option?
- What is the Same Origin Policy, and how does it affect GWT?
- How do I make a call to the server if I am not using GWT RPC?
- Does GWT RPC support java.io.Serializable?
- How can I dynamically fetch JSON feeds from other web domains?
GWT’s network operations are all asynchronous, or non-blocking. That is, they return immediately as soon as called, and require the user to use a callback method to handle the results when they are eventually returned from the server. Though in some cases asynchronous operations are less convenient to use than synchronous operations, GWT does not provide synchronous operations.
It’s important to note that the SOP issues described below are not specific to GWT; they are true of any AJAX application or framework. This FAQ simply details the specific ways in which GWT is affected by this universal limitation.
Typically, the bootstrap process will load the GWT application files from the same web server that is serving the HTML host page. That is, supposing the host HTML file was located at
http://mydomain.com/index.html, the GWT application files would also be in the same directory (or a subdirectory) as the index.html file. To load the GWT application, the
>.nocache.js file would be bootstrapped by having the index.html file include a
> tag referencing the
>.nocache.js file. This is the standard bootstrap process to load a GWT application. The
> tag that needs to be included in the main host HTML page is shown below:
http://static.mydomain.com/. In older versions of GWT, this configuration would not be possible as the SOP prevented the GWT bootstrap process from allowing script from files that were added from a different server to access the iframe in the main host HTML page. As of GWT 1.5, the bootstrap model now provides support for this kind of server configuration via the cross-site linker (xs-linker). As of GWT 2.1, you should however rather use the cross-site iframe linker (xsiframe-linker) which sandboxes the GWT code inside an iframe, like the standard linker but contrary to the cross-site linker.
When using the cross-site linker or cross-site iframe linker, the compiler will still generate a
<module>.nocache.js that you will want to reference within your index.html. The difference though, is that the
<module>.nocache.js produced by the cross-site linkers will link in a cache.js file for each of your permutations rather than a cache.html file.
To enable the cross-site linking simply add the following to your
<module>.gwt.xml and include a reference to your
<module>.nocache.js in your index.html as you normally would.
For more details on the GWT bootstrap process, see “What’s with all the cache/nocache stuff and weird filenames?”
The second area where the SOP is most likely to affect GWT users is the use of XMLHTTPRequest – the heart of AJAX. The SOP limits the XMLHTTPRequest browser call to URLs on the same server from which the host page was loaded. This means that it is impossible to make any kind of AJAX-style request to a different site than the one from which the page was loaded. For example, you might want to have your GWT application served up from
http://pages.mydomain.com/ but have it make requests for data to
http://data.mydomain.com/, or even a different port on the same server, such as
http://pages.mydomain.com:8888/. Unfortunately, both these scenarios are impossible, prevented by the SOP.
This limitation affects all forms of calls to the server, whether JSON, XML-RPC, or GWT’s own RPC library. Generally, you must either run your CGI environment on the same server as the GWT application, or implement a more sophisticated solution such as round-robin DNS load balancing or a reverse-proxy mechanism for your application’s CGI calls.
In certain cases, it is possible to work around this limitation. For an example, see “How can I dynamically fetch JSON feeds from other web domains?”
The SOP applies to all GWT applications, whether running in web (compiled) mode on a web server, or in development mode.
This can cause problems if you are attempting to develop a GWT application that uses server-side technologies not supported by the GWT development mode, such as EJBs or Python code. In such cases, you can use the
-noserver argument for development mode to launch your GWT application from the server technology of your choice. For more information, see How do I use my own server in development mode instead of GWT’s built-in Jetty instance? Even if you choose to use this feature, however, remember that the SOP still applies.
To communicate with your server from the browser without using GWT RPC:
- Create a connection to the server, using the browser’s XMLHTTPRequest feature.
- Construct your payload according to whatever protocol you wish to use, convert it to a string, and send it to the server over the connection.
- Receive the server’s response payload, and parse it according to the protocol.
You must use an asynchronous server connection.
GWT provides a library to largely (though not completely) automate the steps necessary to communicate with the server via HTTP requests. GWT application developers should use the RequestBuilder class and other classes in the
com.google.gwt.http.client.html package, which contains a clean asynchronous server request callback implementation.
Note: New users frequently notice the
com.google.gwt.user.client.HTTPRequest class and attempt to use it. However, the HTTPRequest class is deprecated and will be removed at some point in the future. You should definitely use
If you are attempting to use the RequestBuilder class and are having problems, first check your module XML file to make sure that the HTTP module is inherited, as follows:
- To learn more about alternatives to GWT RPC, see the Developer’s Guide, Making HTTP Requests.
- For a working example of making HTTP requests to retrieve JSON-formatted data, see the Tutorial, Get JSON via HTTP.
- For documentation of the classes and methods you can use to build HTTP requests, see the API Reference, the com.google.gwt.http.client package.
The GWT RPC system does support the use of
java.io.Serializable, however only under a certain condition.
Previous to 1.4, the GWT RPC mechanism used an “IsSerializable” marker interface for denoting classes that can be serialized. Many users expressed the wish to reuse code with GWT that they have already written that used the standard
java.io.Serializable marker interface. Since both interfaces are empty marker interfaces, there is no technical reason why GWT’s RPC mechanism could not use the standard
java.io.Serializable. However, there are good reasons to choose not to do so:
- The semantics of GWT’s serialization are much less sophisticated than standard Java serialization, and so to use
java.io.Serializableas the marker interface would imply that GWT’s serialization system is capable of more than it actually is.
- Conversely, GWT’s serialization mechanism is simpler than standard Java’s, and so to use
java.io.Serializablewould imply that users have more to worry about (such as serialization version IDs) than they actually do.
- GWT implements only a subset of the full Java JRE classes, and specifically implements nothing in
java.io. To use
java.io.Serializableas the GWT RPC serialization marker interface dilutes the message that
java.iois not usable within a GWT application.
While each of the points above still hold, the GWT Team felt that the community was generally aware of these issues but preferred the convenience of being able to use the standard
java.io.Serializable interface rather than to have their classes implement the
isSerializable marker interface, although both marker interfaces to denote serializable classes are supported in GWT 1.4 and later. Considering this, the GWT Team made changes to the GWT RPC system to support the use of
java.io.Serializable for data transfer objects (commonly referred to as DTOs) that would be transferred over the wire. However, there is one condition to enable support for
java.io.Serializable in the new GWT RPC system.
RPC now generates a serialization policy file during GWT compilation. The serialization policy file contains a whitelist of allowed types which may be serialized. Its name is a strong hash name followed by .gwt.rpc. In order to enable support for
java.io.Serializable, the types that your application will send over the wire must be included in the serialization policy whitelist. Also, the serialization policy file must be deployed to your web server as a public resource, accessible from a
ServletContext.getResource(). If it is not deployed properly, RPC will run in 1.3.3 compatibility mode and refuse to serialize types implementing
Another important point to note is that none of the classes that implement
java.io.Serializable in the full Java JRE implement
java.io.Serializable in GWT’s emulated JRE. What this means is that types that implement
java.io.Serializable in the JRE like
StackTraceElement won’t be able to transfer across the wire through GWT RPC since the client won’t be able to serialize/deserialize them. However, this isn’t an issue for other types like
Number, etc… that don’t implement
java.io.Serializable in the emulated JRE but have custom field serializers so that they can be properly serialized.
These differences between types that implement
java.io.Serializable in the real and emulated JREs may be reconciled in a future version of GWT, but for the time this is an important point to keep in mind if your application uses GWT RPC.
Like all AJAX tools, GWT’s HTTP client and RPC libraries are restricted to only accessing data from the same site where your application was loaded, due to the browser Same Origin Policy. If you are using JSON, you can work around this limitation using a
<script> tag (aka JSON-P).
First, you need an external JSON service which can invoke user defined callback functions with the JSON data as argument. An example of such a service is GData’s “alt=json-in-script& callback=myCallback” support. Then, you can use JsonpRequestBuilder to make your call, in a way similar to a
RequestBuilder when you’re not making a cross-site request.