| Issue 389: | Refactor RPC out of RemoteServiceServlet | |
| 13 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
GWT Release: future Detailed description: I perceive RPC as a communication infrastructure between the client and the server. While the client is free to look up any services and invoke freely any of their methods, services are bound to extending the RemoteServiceServlet placing great restrictions on inheritance and dependence. I propose that the RPC mechanism is factored out as a class which can be invoked later. Several ways would be possible like: RPC.invoke(servletRequest, servletResponse, service); or String response = RPC.invoke(rpcContentAsString, service); or (why not?) Invocation inv = RPC.resolve(servletRequest); Object response = inv.getMethod().invoke(service, inv.getArguments()); RPC.respond(response, servletResponse); Workaround if you have one: Links to the relevant GWT Developer Forum posts: |
||||||||||||||
,
Nov 12, 2006
I personally just have my rpc service servlet impl delegate to the real impl with both implementing the interface. Its a minor inconvenience. It keeps things simple and avoids the need for introducing a controller. I realise you have already achieved this with your spring rpc controller package, i suppose such a feature would make that obsolete... :) |
|||||||||||||||
,
Nov 13, 2006
70% of the code in the GWTHandler is about ripping RPC off RemoteServiceServlet in a (hopefully) future-safe way and only the rest is about actually providing spring integration. I'd gladly sacrifice wealth & glory for a simple, open and accessible RPC impl. |
|||||||||||||||
,
Nov 15, 2006
(No comment was entered for this change.)
Owner: gwt.team.mmendez
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low |
|||||||||||||||
,
Nov 22, 2006
Another implementation strategy for this would be to have something like
RemoteServiceDelegatingServlet, an alternate implementation of RemoteServiceServlet.
RemoteServiceDelegatingServlet would have the following key method:
public abstract class RemoteServiceDelegatingServlet {
// ... all the standard GWT RemoteServiceServlet methods ...
public abstract Object invoke (String method, Object[] args);
}
If your server-side servlet mapping was to a subclass of
RemoteServiceDelegatingServlet, GWT would do its normal generic deserialization (in
the base RemoteServiceDelegatingServlet class), then it would call "Object
serviceMethodReturnValue = this.invoke(methodName, arguments)". This would then
do... well, whatever the service author wants, generally delegate via trivial
reflection to a specific server-side implementation component. Then
RemoteServiceDelegatingServlet would do the normal serialization and return the
response.
I only suggest this because I'm not exactly sure what George means by the
"RPC.invoke" method above -- I don't see quite how that integrates with the existing
GWT servlet infrastructure. But then again George already implemented this and I
didn't, so it's probably my problem :-)
See
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/9a4b8ff450151b31/5b7ffd06298981e1#5b7ffd06298981e1
|
|||||||||||||||
,
Jan 08, 2007
I am starting to work on this ( http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/8f1140184070548f ) -- if anyone else is also, please reply to the above thread or post a comment here? My plan is to refactor RemoteServiceServlet into an abstract superclass DelegatingServiceServlet, and a concrete subclass RemoteServiceServlet which will be 100% compatible with the current version. Basically DelegatingServiceServlet will have an abstract method something like "protected abstract Object fetchServiceDelegate (HttpRequest request);" which RemoteServiceServlet implements as "return this;". Then all the existing interface lookup logic will live in DelegatingServiceServlet and will do all the method lookup off the result of fetchServiceDelegate. Net result: RemoteServiceServlet works exactly as it did previously, but any server-side implementors who want to can instead subclass DelegatingServiceServlet, and override fetchServiceDelegate to return whatever existing server-side component they like. Should let George get rid of the 70% of his GWTHandler code that he doesn't want, and should allow g4jsf to have a much more GWT-like RPC mechanism (I will be patching g4jsf to prove that concept as part of this work). Comments welcome. |
|||||||||||||||
,
Jan 08, 2007
Yes! |
|||||||||||||||
,
Jan 12, 2007
Here is a proposed patch. I've refactored RemoteServiceServlet and split big bits of it into three new classes (RPC, RPCCall, and DelegatingServiceServlet, all in the same package). I'm appending all four classes since what I want now is code review. This is not yet ready for final submission! See the link to the above GWT-Contributors thread for more discussion on this. |
|||||||||||||||
,
Jan 12, 2007
Whoops, I left the license header off of DelegatingServiceServlet.java. Sorry about that! Not intentional! Like I said, not ready for final submission :-) |
|||||||||||||||
,
Jan 23, 2007
OK, now I think it's ready for final submission. Please review. I am considering making a test of exception throwing (by extending the existing RemoteServiceServletTest). If that would be helpful to getting this patch accepted, please advise. |
|||||||||||||||
,
Jan 23, 2007
Here is svn diff of RemoteServiceServlet.java against revision 259. If I should generate a patch against head, please advise, but I don't think RemoteServiceServlet.java has moved at all in 1.3.
|
|||||||||||||||
,
Jan 29, 2007
After 28 postings and about 20 pages of discussion on GWT-Contributors, here is an extensively revised patch. Hopefully this is nearing submittability. It passes "ant test" in trunk (of course). The package.html is from com.google.gwt.user.server.rpc. |
|||||||||||||||
,
Jan 29, 2007
:-( There was a bug in RPC.java. Here is the complete patch again with the bug corrected. *Now* it passes "ant test" in trunk. My apologies. |
|||||||||||||||
,
Jan 29, 2007
... |
|||||||||||||||
,
Jan 30, 2007
Aaaand, one minor error in a comment and in the package.html file. Uploading all files again to avoid any confusion about the complete patch contents. |
|||||||||||||||
,
Jan 30, 2007
...missed *one more* comment. This time, uploading only the affected file. The other five files above, in comment #14, are fine. (The error was stating the wrong HTTP status code for failure responses.)
|
|||||||||||||||
,
Feb 01, 2007
(No comment was entered for this change.)
Labels: Category-RPC
|
|||||||||||||||
,
Feb 03, 2007
Fixed many checkstyle errors, though not all (I believe the remaining ones are due to issues with my local environment alone, see the GWT-Contributors thread on issue 389 ). This patch was generated with "svn diff" in trunk/user/src/com/google/gwt/user/server/rpc after updating trunk to revision 353. I have also attached a zip of the files in that directory for reference. |
|||||||||||||||
,
Feb 03, 2007
Omitted to "svn add" new files before running "svn diff". This patch fixes that.
|
|||||||||||||||
,
Feb 05, 2007
Latest patch incorporating Miguel's feedback. As above, generated with "svn diff" in trunk/user/src/com/google/gwt/user/server/rpc at revision 353. |
|||||||||||||||
,
Feb 06, 2007
The only thing worse than uploading a buggy patch is not finding the bug yourself! The decodeRequest(String) method was bugged; it did not properly short-cut the check for whether the interface itself implemented RemoteService. Fixed in isImplementedRemoteServiceInterface, and verified by testing with the g4jsf integration. Looks like this needs a unit test... exception handling probably does too. I may create a separate issue for that, though.... |
|||||||||||||||
,
Feb 06, 2007
Ready for final review! The handleFailure method is now called onUnexpectedFailure, and the RemoteServiceServlet.doPost method is nice and minimal now. |
|||||||||||||||
,
Feb 18, 2007
(No comment was entered for this change.)
Labels: Milestone-1_4_RC
|
|||||||||||||||
,
Mar 22, 2007
Good job Rob.
Status: FixedNotReleased
|
|||||||||||||||
,
May 29, 2007
Changing to Fixed status with GWT 1.4 RC release
Status: Fixed
|
|||||||||||||||
,
Jun 02, 2007
I realize it's too late for 1.4, but what if the RPC mechanism was abstracted/generalized even further, so that the back end does not even have to be java? Is this even possible? It may be heretical even to suggest this (not that I care) but I would love to be able to use a GWT front-end with a Rails back end. JRuby could be the glue here, but if the RPC mechanism was generic enough, it would not need to depend on a particular language; simply use JSON for object serialization.... |
|||||||||||||||
|
,
Apr 28, 2008
Owner: mmendez
|
|||||||||||||||
 Sign in to add a comment
|
|||||||||||||||
