A decent soln, but IMHO still a bit of work and it requires @GWTRequestMapping One should be about to get away without even using that annotation Yes, your soln is better than gwt-dispatch, but I still think we can write an even better soln.
Cheers, Henry On Jan 24, 2:50 pm, jarrod <jarrod.carl...@gmail.com> wrote: > 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 <q8e...@gmail.com> 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 <olivier.nougu...@gmail.com> > > 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 <q8e...@gmail.com> 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 <olivier.nougu...@gmail.com> > > > > 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 <q8e...@gmail.com> 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 > > > > google-web-tool...@googlegroups.com. > > > > > > To unsubscribe from this group, send email to > > > > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > > > > > > cr...@googlegroups.com> > > > > <google-web-toolkit%2bunsubscr...@googlegroups.com<google-web-toolkit%252Bu > > > > nsubscr...@googlegroups.com> > > > > > > > . > > > > > > 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 > > > > google-web-tool...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > > > > cr...@googlegroups.com> > > > > . > > > > 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 google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
