[
https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631311#action_12631311
]
Mathias Herberts commented on THRIFT-137:
-----------------------------------------
As previously discussed on the mailing list I have also worked to make
integrating Thrift structs and services with GWT easier.
Here is the path I followed.
I patched the Thrift compiler to accept an additional options for Java code
generation, namely 'gwt'.
When this option is specified, the Java generator generates classes for structs
in a 'gwt' subpackage of the specified namespace. Those classes are slightly
modified versions of the normally generated classes. The modifications are
simply the removal of the TBase inheritance, the removal of any hashcode method
(as StringBuilder is not supported by GWT) and the inclusion of the isset field
as non final and as part of the constructor.
A helper class has been written which using reflection converts from a Thrift
TBase to its GWT counterpart.
For services, a mirror class of the Thrift one is created in the 'gwt;
subpackage, this class has two inner interfaces, one for the regular service,
the other one for the Async version.
I'll add my patch to this issue so anyone interested can have a look.
> Asynchronous client transports
> ------------------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: thrift-gwt.diff
>
>
> As previously discussed on the mailinglist, using Thrift from Google Web
> Toolkit (GWT) applications (AJAX) would be nice, as it does not only allow
> you to consume existing Thrift services from GWT applications, but also means
> that you now can write GWT-consumable RPC services in any language (and say
> host them on Google Appengine) that are practically source-code compatible
> with the official GWT RPC framework.
> Doing this presents two challanges:
> 1) The GWT compiler only supports a subset of the JRE libraries (luckily,
> this is rather easy to work around).
> 2) As the A in AJAX hints, the only way of doing RPC is asynchronously,
> something not supported by Thrift, by using the XMLHttpRequest object in the
> browser.
> Here's what I've done (an excerpt from the mailing-list):
> --snip--
> 1) Created a stripped down jar of Thrift, axed most protocol, transport and
> server implementations, in order to get a JavaScript-translatable version of
> Thrift. I did not need to change any of the base Thrift classes, nor modify
> the compiler for GWT to translate the structs, but I might have missed
> something here (Mathias?).
> 2) Added an option for the Thrift Java compiler to generate asynchronous
> service interfaces and client proxies. This is manifested as:
> public class Repository {
> public interface Iface {
> public Document get_document(String uri) throws TException;
> public int get_count() throws TException;
> }
> public interface AsyncIface {
> public void get_document(String uri, TAsyncCallback<Document>
> callback) throws TException;
> public void get_count(TAsyncCallback<Integer> callback) throws TException;
> }
> ...
> This is done in line with GWT's RPC framework and gives the developer the
> standard synchronous interface to implement on the server side (I use it with
> embedded Jetty in a daemon) and an asynchonous interface to use in the GWT
> client. AsyncCallback<T> just has a plain onSuccess(T result) method.
> 3) Implemented a client transport using GWT's RequestBuilder (the
> XmlHttpRequest abstraction) that executes the TAsyncCallback asynchronously
> when the response has been received.
> 4) Modified the JSONProtocol slightly to be fully JavaScript-translatable.
> This could probably be more efficiently done by using GWT's JSNI framework,
> but I really haven't had the time to optimize anything yet.
> --snip--
> This solution works really well for my problem, but it's half-assed in two
> ways.
> 1) It only allows for asynchronous client transports (as in the case of the
> XMLHttpRequest object) and not on the server side (with messages coming back
> in a non-sequential order).
> 2) I'm not sure how to solve the client library issues. Right now, I've moved
> the core classes (those required on the client (GWT) side of things) into
> com.facebook.thrift.gwt, while keeping everything else where they are. This
> allows the GWT compiler to translate com.facebook.thrift.gwt.* while using
> the same jar both on the client and server. This is not very elegant for
> people not using GWT (which I suppose is 99.99% of the audience) but short of
> maintaining two separate Java client libraries, I'm not sure how to solve
> this issue.
> The attached patch is only for the compiler, and does not produce compilable
> client code without the modified client library. Just wanted to get some
> input before producing a somewhat committable patch. Comments? Ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
