[
https://issues.apache.org/jira/browse/THRIFT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Meier resolved THRIFT-137.
--------------------------------
Resolution: Won't Fix
issue is too old, please reopen or create a new issue and patch if you need
this.
see http://thrift.apache.org/docs/HowToContribute/
> GWT support for Thrift
> ----------------------
>
> Key: THRIFT-137
> URL: https://issues.apache.org/jira/browse/THRIFT-137
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Compiler, Java - Library
> Reporter: Fredrik Hedberg
> Priority: Minor
> Attachments: GWTHelper.java, thrift-compiler-gwt-path,
> thrift-gwt-2.diff, thrift-gwt-3.diff, thrift-gwt-4.diff, 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
