Hi Henry, You can implement it using child injector:
Below code is from http://stuffthathappens.com/blog/2009/09/14/guice-with-gwt/ with modifications @Singleton public class GuiceRemoteServiceServlet extends RemoteServiceServlet { ... @SuppressWarnings({"unchecked"}) private RemoteService getServiceInstance(final Class serviceClass) { // OLD return (RemoteService) injector.getInstance(serviceClass); // determine the Impl class from serviceClass using naming convention final Class implClass = ... ; Injector dynamicInjector = injector.createChildInjector(new AbstractModule(){ protected void configure() { bind(serviceClass).to(implClass); } }); return dynamicInjector.getInstance(serviceClass); } } For every RPC request, it bind the serviceClass to the implClass dynamically. But you will pay for the performance (I did not measure it yet :( ) Hope this help, Trung http://www.gdevelop.com/ On Jan 28, 10:42 am, Henry <[email protected]> wrote: > I use the Eclipse-plugin to help me write the async, > but that's got nothing to with my proposed dispatcher ... unless > there's something you forgot to mention > > Cheers, > Henry > > On Jan 27, 6:31 am, Alexander <[email protected]> wrote: > > > You write async version of interface manualy? > > > 2010/1/25 jarrod <[email protected]> > > > > Have you looked at the GWT-SL library? This is the project I use to > > > export my RPC services with Spring. It is blisteringly easy. > > >http://gwt-widget.sourceforge.net/gwt-sl/reference-1.0/index.html#RPC > > > > The great thing about this library is that (except for one line in > > > your servlet context) configuration is completely annotation-driven! > > > > I just place this line in my-servlet.xml: > > > <bean class="org.gwtwidgets.server.spring.GWTHandler" /> > > > > The GWTHandler works as a HandlerMapping, so it can be ordered among > > > other HandlerMappings as you see fit. > > > > Next, I can wire-up RPC services like so: > > > > First, the RPC Interface > > > > @RemoteServiceRelativePath("UserService.rpc") // service path for > > > client side, relative to module path > > > @GWTRequestMapping("/foo.bar.users.Users/UserService.rpc") // service > > > path for server side, relative to context > > > public interface RpcUserService extends RemoteService { > > > > void deleteUser(String uid); > > > > User getUser(String uid); > > > > List<User> listUsers(); > > > > void updateUser(User user); > > > > } > > > > And the accompanying Async version: > > > > public interface RpcUserServiceAsync { > > > > void deleteUser(String uid, AsyncCallback<Void> callback); > > > > void getUser(String uid, AsyncCallback<User> callback); > > > > void listUsers(AsyncCallback<List<User>> callback); > > > > void updateUser(User user, AsyncCallback<Void> callback); > > > > } > > > > I won't go into the client side usage, but on the server side, it > > > works just like this: > > > > @Component // Spring auto-detects and wires up this POJO > > > // because this is an RpcUserService, the GWTHandler will export it > > > automatically! > > > public class UserServiceImpl implements RpcUserService { > > > > private UserService service; // some backing bean > > > > �...@autowired > > > UserServiceImpl(UserService service) { > > > this.service = service; > > > } > > > > �...@override > > > public void deleteUser(String uid) { > > > this.service.deleteUser(uid); > > > } > > > > �...@override > > > public User getUser(String uid) { > > > return this.service.loadUser(uid); > > > } > > > > �...@override > > > public List<User> listUsers() { > > > return this.service.listUsers(0, 1000); > > > } > > > > �...@override > > > public void updateUser(User user) { > > > this.service.updateUser(user); > > > } > > > > } > > > > In this case, my application already had a server side component > > > (UserService) to handle my requests. My POJO here is just a stupid- > > > simple wrapper around that backend service object. Your mileage may > > > vary, though. > > > > That's it! There are no additional "configurations" to do, regardless > > > of how many RPC services you want to make available. If all of your > > > service's dependencies are made known to the container through the > > > @Component annotation, then you won't even have to configure those in > > > a Spring config file... > > > > I hope that helps solve the concern you're addressing. > > > > On Jan 24, 2:06 pm, Henry <[email protected]> wrote: > > > > The issue is that I have to maintain a DI configuration file. > > > > If I have say 50 rpc services, then that means I'll have a DI file > > > > with 50 lines of DI injection. > > > > > Cheers, > > > > Henry > > > > > On Jan 24, 2:38 am, olivier nouguier <[email protected]> > > > > wrote: > > > > > > hi, > > > > > I can't figure out what you consider an issue in using a DI > > > > > dispatch. > > > > > Just to understand :) > > > > > > On Sun, Jan 24, 2010 at 8:15 AM, Henry <[email protected]> wrote: > > > > > > I took a quick look at > > > >http://code.google.com/p/orcades-gwt-spring/wiki/orcadesGWTSpringHandler > > > > > > Not bad, but it still needs managed beans which is managed via a > > > > > > .xml > > > > > > file or annotations. > > > > > > I'm suggesting something that doesn't even need that ... > > > > > > the caveat is that my soln uses a name-design pattern (which might > > > not > > > > > > be a caveat) > > > > > > > Cheers, > > > > > > Henry > > > > > > > On Jan 23, 2:16 am, olivier nouguier <[email protected]> > > > > > > wrote: > > > > > > > Hi > > > > > > > It's quite easy to implement a GWT dispatcher. At least with > > > spring, > > > > > > then > > > > > > > use autoscan feature: > > > >http://code.google.com/p/orcades-gwt-spring/wiki/orcadesGWTSpringHandler > > > > > > > HIH > > > > > > > > On Fri, Jan 22, 2010 at 7:13 PM, Henry <[email protected]> wrote: > > > > > > > > So far, > > > > > > > > > I found there are a few ways to redirect your serviceimpl, > > > > > > > > namley > > > > > > > > 1) logic in web.xml > > > > > > > > 2) gwt-dispatch > > > > > > > > 3) various framework plugins (for struts, jsf) > > > > > > > > > But each of these solns above require you to edit a config file > > > (or > > > > > > > > modify a java file with guice) > > > > > > > > everytime you add a new serviceimpl. > > > > > > > > Would it be possible to have an auto-config, so that if you > > > follow the > > > > > > > > standard naming > > > > > > > > convention of > > > > > > > > XXXService.java > > > > > > > > XXXServiceAsync.java > > > > > > > > XXXServiceImpl.java > > > > > > > > > that you won't have to add any more configurations. > > > > > > > > i.e. > > > > > > > > the service endpoint is something like > > > > > > > > /gwt/GwtNameDispatcher > > > > > > > > > and GwtNameDispatcher is written so that it invokes the > > > respective > > > > > > > > ServiceImpl > > > > > > > > w/o reading any configs files. GwtNameDispatcher knows which > > > > > > > > ServiceImpl to invoke > > > > > > > > based upon what Service object was passed in the GWT-RPC post > > > param. > > > > > > > > The caveat is that you must follow the > > > > > > > > XXXService.java > > > > > > > > XXXServiceAsync.java > > > > > > > > XXXServiceImpl.java > > > > > > > > pattern, but if I write such a GwtNameDispatcher beast, would > > > this be > > > > > > > > useful > > > > > > > > to the GWT community? > > > > > > > > Is there a better soln? > > > > > > > > > Cheers, > > > > > > > > Henry > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the > > > Google > > > > > > Groups > > > > > > > > "Google Web Toolkit" group. > > > > > > > > To post to this group, send email to > > > > > > [email protected]. > > > > > > > > To unsubscribe from this group, send email to > > > > > > > > [email protected]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > > > [email protected]> > > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]><google-web-toolkit%252Bu > > > [email protected]> > > > > > > > > > . > > > > > > > > For more options, visit this group at > > > > > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > > > > > -- > > > > > > > A coward is incapable of exhibiting love; it is the prerogative of > > > the > > > > > > > brave. > > > > > > > -- > > > > > > > Mohandas Gandhi > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > > "Google Web Toolkit" group. > > > > > > To post to this group, send email to > > > [email protected]. > > > > > > To unsubscribe from this group, send email to > > > > > > [email protected]<google-web-toolkit%[email protected]><google-web-toolkit%2Bunsubs > > > [email protected]> > > > > > > . > > > > > > For more options, visit this group at > > > > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > > > > -- > > > > > A coward is incapable of exhibiting love; it is the prerogative of the > > > > > brave. > > > > > -- > > > > > Mohandas Gandhi > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google Web Toolkit" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<google-web-toolkit%[email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > -- > > Regards, > > Alexander > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
