Hi Trung, So you do agree that writing a dispatcher can be done. Whether you use Guice, Spring or reflection to accomplish this hasn't been done yet. My real question, is ... is this useful? As for performance ... well, my gut feel is that it can be written just as efficiently as all the other dispatchers right now. Am I wrong on this assumption?
Cheers, Henry On Jan 28, 4:11 am, Trung <[email protected]> wrote: > Hi Henry, > > You can implement it using child injector: > > Below code is fromhttp://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, > Trunghttp://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.
