gwtrpc-spring sous maven

Comme son nom l’indique, la librairie gwtrpc-spring simplifie l’intégration de GWT et Spring.
Malheureusement, elle n’est pas mavenisée.

J’ai donc déployé dans notre repo public une version avec un pom le plus propre possible, notamment compte-tenu de la dépendance à beanlib dont le pom est franchement bordélique.

Cette version est basée sur le trunk à ce jour, mais les dépendances ont été mises à jour autant que possible.

1
2
3
4
5
<dependency>
  <groupId>org.gwtrpcspring</groupId>
  <artifactId>gwtrpc-spring</artifactId>
  <version>1.02.excilys1</version>
</dependency>
VN:R_U [1.9.22_1171]
Rating: 0 (from 0 votes)
Share
Ce contenu a été publié dans Non classé, Spring, avec comme mot(s)-clef(s) , . Vous pouvez le mettre en favoris avec ce permalien.

8 réponses à gwtrpc-spring sous maven

  1. Anthony Coulon dit :

    Un framework très pratique, facile d’utilisation et qui simplifie grandement la vie dans un monde remplie de GWT et de Spring !!

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. Intéressant. Quelques notes (en mode bashing) :

    • Sympa de faire un packaging Maven, mais pourquoi ne pas l’avoir contribué directement au projet ? Ils n’en veulent pas / ne répondent pas ?
    • “The gwtrpc-spring jar allows for simple integration of Spring and GWT 1.6″ => visiblement ils sont plus trop au goût du jour :-)
    • Aucun intérêt par rapport à une intégration Spring à la mano. On est obligé de se taper une déclaration dans le web.xml pour chaque service, + une déclaration dans le fichier de context Spring… débile ! Du coup, ça revient beaucoup plus simple de faire dans l’init de la servlet un coup de SpringServletHelper.inject(this);*
    • Une approche mieux intégrée à Spring serait plus intéressante (ne pas toucher aux web.xml, et ne pas devoir étendre Servlet)
    • A quoi ça sert ça : http://code.google.com/p/gwtrpc-spring/source/browse/trunk/src/org/gwtrpcspring/gilead/GileadAdapterAdvice.java ?
    • Marrant le bean translator :-) : http://code.google.com/p/gwtrpc-spring/source/browse/trunk/src/org/gwtrpcspring/mapping/Translator.java
    • Pour résumer, une investigation rapide montre le peu de sérieux de la chose… ça reste mon avis : passez votre chemin.

    * Code de SpringServletHelper :

    
    
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    public class SpringServletHelper {
       
        public static void inject(HttpServlet servlet) {
            ServletContext servletContext = servlet.getServletContext();
            WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext);
            AutowireCapableBeanFactory beanFactory = applicationContext.getAutowireCapableBeanFactory();
            beanFactory.autowireBeanProperties(servlet, AutowireCapableBeanFactory.AUTOWIRE_BY_NAME, true);
        }

    }
    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. J’ajouterai par ailleurs que Spring4gwt, bien que pas forcément à jour, me paraît avoir une bien meilleure approche : http://code.google.com/p/spring4gwt/wiki/SimpleRPCExample

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. Par ailleurs, je suis allé un peu vite en besogne : il n’est besoin que d’un seul servlet-mapping. L’exemple donné m’a induit en erreur (/myapp/greet). La détermination se fait sur le nom de classe du service visé, passé dans le corps de la requête.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  5. A la réflexion, il semble bien qu’en prime on puisse tenter une attaque, un peu sur le principe de l’injection. Le code du dispatcher est ici : http://code.google.com/p/gwtrpc-spring/source/browse/trunk/src/org/gwtrpcspring/RemoteServiceDispatcher.java

    GWT RPC, dans son protocole, fournit dans chaque requête la classe du service appelé.

    Or, ici, cette valeur est extraite, on récupère la classe du même nom (Class.forName), puis on demande à Spring de nous fournir un bean de ce type. Sans vérifier. A tester, mais il semblerait qu’en filant un autre nom de classe, on puisse bien intéragir avec n’importe quel bean de l’application contexte. C’est même logique, puisqu’à aucun endroit on a défini la liste des services exposés.

    Une solution éventuelle : isoler les services, en ne laissant dans l’application context en question que les services exposés. Et en corrigeant le framework pourqu’il n’aille pas regarder chez papa si j’y suis (pas d’héritage dans le lookup de bean quoi)

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  6. Alors, dans l’ordre :

    • Je n’ai pas (encore) cherché à contribuer la mavenisation car :
      • J’étais pressé, et dans un premier temps, on n’est jamais mieux servi que par soi-même
      • le projet ne semble plus évoluer (ce qui ne veut pas dire qu’il est obsolète mais peut-être juste qu’il a atteint ses objectifs)
      • des gars d’Octo avaient abordé le sujet maven avec les développeurs et avaient fini par déployer la lib chez eux (mais avec un pom vide)
    • Vu ce qu’adresse la lib, elle est à première vue compatible avec GWT 2.3
    • Justement, on ne déclare plus que la servlet de la lib dans le web.xml en la mappant sur autant d’url que de services RCP, et elle délègue au composant Spring souhaité qui n’a qu’à étendre l’interface (sans hériter de RemoteServlet donc)
    • Je ne vois pas comment se passer d’un web.xml?
    • De mémoire, Gilead sert si tu souhaites retourner directement une grappe d’entités Hibernate plutôt que des DTO. Il s’appuie sur Beanlib pour copier ta grappe en filtrant tous les proxies non initialisés et éviter ainsi lors de la sérialisation de soit charger toute ta base, soit de te prendre des LazyInitializationException selon ta stratégie de gestion de la session
    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  7. Ok merci :-) .

    “Je ne vois pas comment se passer d’un web.xml?” Je parlais de la différence entre l’approche traditionnelle (n services = n servlet = n déclarations dans le web.xml), et l’approche type contrôleur spring mvc (n services = 1 dispatcher servlet = 1 déclaration dans le web.xml). Mais effectivement, on est bien dans ce cas, là, je me suis trompé.

    Reste la potentielle faille de sécu évoquée plus haut. A creuser.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  8. Non, on n’est pas tout à fait dans ce cas car si l’on ne déclare bien qu’une seule servlet, on déclare autant de servlet-mapping que de services au sens GWT RPC.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)

Laisser un commentaire