GWT-Spring Integration Demystified

Discussions

News: GWT-Spring Integration Demystified

  1. GWT-Spring Integration Demystified (9 messages)

    As posted on Ajaxian, Gabi S has posted "GWT-Spring Integration Demystified," illustrating one possibility for integrating Spring and the Google Web Toolkit. Gabi walks through the entire build process, with a Spring servlet controller delegating to an injected GWT remote service. This isn't the only way to integrate GWT and Spring on the server side; another alternative is to have the asynchronous GWT services themselves look up resources in Spring (allowing injection of resources, aspects, etc.) and delegate method calls. This doesn't add the benefits of the Spring-MVC servlet delegation class, however. (This may not be all bad: the DispatcherServlet normally manages a view as well, and GWT's remote services would need to ignore this functionality.)
  2. I'm not too sure what the advantages of this integration are. GWT in essence manages its own state and navigation issues do not really exist any more as far as I understand. GWT and Swing-based applets are somewhat similar and can be considered as rich clients in that they manage the MVC events locally using the client's CPU. Navigation and views can entirely be managed in JavaScript, even though it's possible to hit the Back/Forth button or open a new window/tab, which can also be managed locally as well with GWT history and hidden frame. Therefore, I believe there's no real need whatsoever for any external engine like Struts or Spring MVC. I must have genuinely missed something here. Can someone explain what the point of this integration is ? Many thanks. Yann
  3. Cool, thats a nice bite sized example! No, Spring is not being used for its MVC capability. In this example, its just a way to loosely couple servlets from the service implementation, using Springs BeanFactory. With GWT a lot of the logic is coded in java, compiled and converted to javascript and executes directly on the browser... This client(browser) side code calls 'services' via GWT's RPC mechanism and then probably executes more code to display the results etc... No Spring code is running on the browser, and theres no use of MVC pattern in this example... Theres a few reasons why the implementors of the server side business logic would use Spring. One reason is the class implementing the logic com.server.MyServiceImpl.java is a POJO and can be unit tested etc independently... Hope this helps and hasn't confused things further
  4. Garry, Thanks for your reply. Things are clearer regarding MVC now. :) Actually, I was confused with the following sentences: "What makes GWT more interesting is that it can be integrated with technologies like Struts, ..." and "This doesn't add the benefits of the Spring-MVC servlet delegation class, however." Together with the use of the AbstractController which is part of the MVC package, it was a bit confusing. Also, I would not have thought that integration with Spring would be considered as a mystery. Actually, the solution proposed in this blog entry seems more complex than what's described in Ed Burnette's booklet "GWT - Taking the pain out of AJAX" chapter "GWT RPC basics". It is still unclear what this integration solution really brings to the table. The only thing I can see is that it makes it possible to use IoC on the servlet instance itself which may be nice for trace logs and profiling info for instance but which could also be made easily available somewhere else (in the business layer for instance). Just wondering. Yann
  5. Hi Yann, Yeah, I share your confusion on statements like that, too much marchitecture flying around.... What i liked about it was its a nice short article with a complete client to server example. Ive been looking for a complete end to end example with build scripts etc... And also using Spring to keep the 'services' business logic portable. Today they may be executed on the server and invoked by servlets, maybe they'll be moved to the client for some users... Thanks for the link to your blog Luca
  6. It's not only old stuff (look at this), but you don't need to write any custom code or controller to integrate it !!!! It's enough to use a servlet adapter to integrate: <!-- Adapter to use the Servlet interface with the generic DispatcherServlet. Calls the Servlet's service method to handle a request. --> Ciao.
  7. I introduced use of Spring Framework for developing JMS message-driven beans just for the advantages Spring offers in terms of its IoC functionality. (Remember, that was originally what Spring was all about...) So now the MDBs are composed of simple POJO Spring beans and are easier to write unit test for. At any rate, the thing I love best about GWT is that it's an approach to web applications that is very close to how my current C# .NET Winforms rich client apps are developed. One just writes beans in the middle-tier to process messaging interactions with those. And now using GWT, can just write servlets that process similar async RPC interactions. (In fact could write a single servlet that bridges to my JMS msg broker, so that writing the service layer for GWT clients would be the same process and technique as for the .NET clients. Still need to solve server-push back to those GWT clients...) The good news here is there is no more monstrosity of the MVC web framework in the middle-tier. The client keeps track of its state - as it should. The middle-tier is nothing but discreet services that anything can call. No more having a client joined at the hip to some crazy, whacko web framework on the server-side, which was completely anti-SOA. A web framework is the ultimate anti-pattern. Development along the lines of what GWT will enable is much easier and far more flexible. GWT spells an end to the predominance of the web 1.0 way of developing web applications, and for that there is cause for much rejoicing.
  8. Very quickly since this posting, RIA technologies have become all the rage: GWT Flex 2 Silverlight JavaFX It's all we talk about now on the forums. Web frameworks are looking very much like the dinosaurs now. And that's a very good thing. Have been down on web frameworks or server-side processing of UI via the web approach since its very advent. Is a shame has taken RIA so long to finally come into its own. And Ruby on Rails? How utterly passe.
  9. This may not be all bad: the DispatcherServlet normally manages a view as well, and GWT's remote services would need to ignore this functionality.
    FWIW, while Spring's DispatcherServlet does indeed offer built-in view support, this is only at a very fundamental level: A handler defined in a dispatcher *may* expose a View to be returned, which is just a formal abstraction for the process-request-then-render-view workflow. There is no assumption of specific kinds of views at the dispatcher level: The view could be an InternalResourceView wrapper for a JSP, rendering HTML content, or a subclass of AbstractPdfView, rendering binary PDF content to the OutputStream, or a RedirectView which just tells the client to redirect to a different URL. The DispatcherServlet itself remains completely agnostic there. Reflecting that design, Spring 2.0's DispatcherServlet supports different kinds of handler interfaces: an MVC Controller, which explicitly allows for returning a View, as well as an HttpRequestHandler, which explicitly does *not* deal with Views but rather has a plain Servlet-like signature (HttpServletRequest, HttpServletResponse). As pointed out in a post above, DispatcherServlet is even able to deal with raw Servlet instances defines as Spring beans, through using Spring's SimpleServletHandlerAdapter: still providing its flexible handler mapping capabilities, exception resolution options, and of course dependency injection on handler beans. So Spring's DispatcherServlet is explicitly designed for MVC-style controllers/views as well as for straight HTTP request processors. As a consequence, using it for remoting-style HTTP request processing is a perfectly fine scenario: Spring applications have been doing this for years already, when using Spring's Hessian, Burlap or HTTP invoker support: all of them being HTTP-based binary/XML remoting protocols, with the exporters defined as Spring beans in a DispatcherServlet context, receiving target service instances via dependency injection, etc. GWT's remote services naturally fall into the same category, I would argue! Juergen (Spring Team)
  10. Spring applications have been doing this for years already, when using Spring's Hessian, Burlap or HTTP invoker support: all of them being HTTP-based binary/XML remoting protocols, with the exporters defined as Spring beans in a DispatcherServlet context, receiving target service instances via dependency injection, etc. GWT's remote services naturally fall into the same category, I would argue!
    I actually implemented a simple GwtInvokerServiceExporter when GWT was first released. http://jelmer.jteam.nl/?p=5 The code is temporarily offline now but there a commenter posted an updated version