gwtrpc-spring répond à ces limitations, il faut bien l'avouer, de façon trés élégante.
Configuration de la partie Serveur : une simple exposition de beans Spring Exposer un service GWT-RPC nécessite deux choses :
Peu de choses a priori mais autant de défauts potentiels qui ne seront détectés qu'au déploiement et qui, au final, freinent la productivité.
gwtrpc-spring propose un fonctionnement un peu plus générique (une documentation plus complète est disponible sur le site) :
une servlet de type "Dispatcher" unique à configurer dans le fichier web.xml.
...
<servlet -mapping>
</servlet><servlet -name>dispatcher</servlet>
<url -pattern>*.rpc</url>
...
tout bean Spring peut être alors exposé via l'annotation @Service. Vous noterez que l'implémentation du service n'hérite pas de RemoteServiceServlet. Il est possible d'avoir les mêmes API via la classe statique RemoteServiceUtil.
@Service
public class GreetingServiceImpl implements GreetingService {
la configuration Spring associée peut être générique
...
<context :annotation-config />
<context :component-scan base-package="org.octo.myapp.server" />
...
Ainsi configurés, toutes les appels sur des urls se terminant par *.rpc seront "dispatchés" vers le "bon" bean Spring ie. l'implémentation du contrat de service.
Configuration de la partie Cliente : du GWT, simplement L'élégance de ce framework tient en partie dans son intégration transparente dans la partie cliente. En effet:
l'interface de service utilise toujours et uniquement les annotations GWT.
@RemoteServiceRelativePath("greet.rpc")
public interface GreetingService extends RemoteService {
la création du service via l'API GWT.create() est identique
greetingService = GWT.create(GreetingService.class);
En bref, un framework simple et élégant...