Re: GWT Spring integration - what is the best method in late 2010?

Any other feedback about this ?
What's odd is that we are still asking this very same question after
several years of existence of both frameworks, don't you think ?

So, we have :
- GWT SL
- Spring4GWT
- Gwt-dispatch
- gwt-spring

(My) Questions are :
- which of them are still maintained ?
- which of them do provide a compatibility with the latest versions of
GWT and Spring ?
- which of them are non intrusive ?

David

On 20 sep, 23:41, Jason Hatton <jashat...@gmail.com> wrote:
> Hey lalit,
>
> I will take a look at this further this was and example of how to implement
> Spring on a previous version and is basically the servlet example class I
> posted earlier.  I will take a look at the newer version of gwt-dispatch to
> see what else has been included.  We were waiting on upgrading but this
> peaks my interested on upgrading sooner.  WebApplication context is just
> Spring's way of bootstrapping an application context in a web container.
>  What that class does is grab the application context wires in the
> DispatchServlet so POJOS can be injected in to all the classes it supports.
>  Definitely it is in the spring-web jar  but it appears that is the only
> Spring feature gwt-dispatch project takes advantage of.  If you take a look
> at the ActionHandler and base dispatch classes you don't see any other
> Springy stuff.
>
> Gwt-dispatch helps us to avoid having to code the separate interfaces.  We
> just code actions, action handlers, and result objects.  All the dispatch
> traffic routes through the one GWT-RPC service that gwt-dispatch implements.
>  All the async workings have to be there but, we get to work on valuable
> object interactions and avoid ceremonial grunt work which always makes
> coding more fun.
>
> Later,
> Jas
>
> On Fri, Sep 17, 2010 at 1:12 AM, lalit <lalit.bh...@gmail.com> wrote:
> > Hi Jason,
>
> > I agree that both the approaches are same. But I still have a feeling
> > that gwtDispatch uses Spring MVC infra to do its job. The code that
> > you have posted above has WebApplicationContext. Also I looked into
> > gwtDispatch code and it seems it is using Spring MVC infra. The code I
> > looked into is here
>
> >http://code.google.com/p/gwt-dispatch/source/browse/src/main/java/net...
>
> > Another thing you mentioned in your mail that you do not have to code
> > two interfaces which looked interesting. If possible can you elaborate
> > on that? We would like to incorporate that in our approach also if
> > possible.
>
> > thanks,
>
> > On Sep 16, 7:15 pm, Jason Hatton <jashat...@gmail.com> wrote:
> > > Lalit we are not using Spring MVC.  We am using gwt-dispatch and have
> > > extended that project's dispatch servlet to get the Spring integration.
> >  We
> > > then added a custom annotation to pick up the appropriate dispatch action
> > > handler for a particular GWT-RPC on the server side.  All of our GWT-RPC
> > > calls go through this servlet so we avoid the overhead and code bloat of
> > > having to create the standard GWT-RPC interfaces for every new service
> > call
> > > we want to implement.  I looked over your example again and they are
> > pretty
> > > similar.  I like your integration approach with Spring but I prefer
> > service
> > > call handling because we don't have to code the two separate RPC
> > interfaces,
> > >  i.e. the Service and ServiceAsync for every service we want to
> > implement.
> > >  We just create an new dispatch handler apply an annotation to it and we
> > are
> > > off and running.
>
> > > On Wed, Sep 15, 2010 at 11:33 PM, lalit <lalit.bh...@gmail.com> wrote:
> > > > Deepak - I have used the following structure
> > > >   SpringApplicationContext, SpringGwtRemoteServiceServlet ,
> > > > PersonServiceImpl go into the server side code.
> > > >  The interfaces PersonService and PersonServiceAsync  become part of
> > > > GWT client side code.
>
> > > > Regarding wsdl files consumption see the section on JAX-WS here
> > > >http://www.lalitbhatt.com/tiki-index.php?page=JAX-WSespeciallJAX-WS
> > > > client side section. This approach uses JAX-WS approach.
>
> > > > For data binding you can use JAXB. The details can be seen here
> > > >http://www.lalitbhatt.com/tiki-index.php?page=JAXB. JAX-WS anyway uses
> > > > it internally.
>
> > > > Also just a disclaimer, the approach I took is as per Spring4GWT
> > > > project so it's there idea.
>
> > > > Jason- I looked into your approach and conceptually they look similar
> > > > in terms of that you are redirecting the request to Spring MVC
> > > > infrastructure. IMHO the aprroach I took as per Sping4GWT is better as
> > > > one does not have to carry the SpringMVC baggage.
>
> > > > --
> > > > 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-toolkit@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubscribe@googlegroups.com><google-web-toolkit%2Bunsubs
> > cribe@googlegroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> > --
> > 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-toolkit@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.

--
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-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.