This reflection on the servlet itself is contrary to the best practices
for inversion of control frameworks such as EJB3, Spring, etc., where
it is generally bad practice to force your business or service classes
to extend anything from any framework.
People have already started working around this at considerable expense
-- a great example of the kind of workaround that is necessary is here:
http://g.georgovassilis.googlepages.com/usingthegwthandler
But why in heaven's name should we have to do a bunch of Java bytecode
generation on the server just to do some simple reflective delegation?
What would be about 1,000 times better would be if GWT itself had a
generic reflective delegate on the server side. I would propose
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'm 99% sure implementing this would actually add *no code whatsoever*
to GWT -- it would really be *saving* GWT some work since GWT wouldn't
need to do its own reflective method lookup! (Of course the current
RemoteServiceServlet would need to be supported for backwards
compatibility, but pretty rapidly you'd get a SpringDelegatingServlet,
JSFDelegatingServlet, etc., that would be the ONLY servlets you'd need
for any of those various server-side frameworks.)
Doing this would greatly ease the lives of service authors who already
have server-side components (possibly many of them) that they want to
expose to GWT services, without forcing them to write a plethora of
glue servlets or mung around with CGLIB.
Thoughts? I will post this as a feature request if anyone else agrees
this would be useful :-) What I really want is to get this kind of
structure implemented in g4jsf and Seam, to allow exposing EJB3
components generically as GWT services. But I'd *really* rather not
port the Spring GWTHandler CGLIB magic into the g4jsf world when
there's so little added value in doing so....
Cheers!
Rob
http://code.google.com/p/google-web-toolkit/issues/detail?id=389
Star it if you want it!
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/8f1140184070548f
George, please take a look?
Cheers!
Rob Jellinghaus