DynaResume


Cette page liste tous les billets inititulés « Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM » :

Step Extrait
[step0] Intoduction sur les billets intitulés « Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM » et le projet « DynaResume ».
[step1] Mise en place de projets Java classiques Client/Services/Domain en évoquant les problématiques engendrées par les dépendances classiques Java (Impossible de faire cohabiter des JARs de différentes versions, Impossible de protéger des classes qui ne doivent pas être utilisées par d’autres projets…).
[step2] Intoduction à OSGi et de ses concepts (Target Platform). Mise en place de notre premier bundle OSGi Domain.
[step3] Mise en place des bundles OSGi Client/Services/Domain en montrant comment OSGi résoud les problématiques engendrées par les dépendances classiques Java.
[step4] Intoduction aux registres de services OSGi, de son interêt de sa mise en oeuvre.
[step5] Bonne pratiques à suivre dans les bundles OSGi :
* scinder en 2 bundles les service API et Implémentation.
* favoriser les dépendances de type « Import Package » à « Require Bundle »
[step6] Intoduction à Spring (Framework), de son intêret et de sa mise en oeuvre.
[step7] Intoduction à Spring Dynamic Module, de son intêret et de sa mise en oeuvre pour déclarer l’enregistrement des services OSGi via <osgi:service.
[step8] Mise en oeuvre de Spring Dynamic Module pour déclarer la consommation des services OSGi via <osgi:reference.
[step9] Introduction à l’architecture Client/Serveur. Mise en place de Spring Remoting coté serveur, dans une application WEB classique pour exposer des services via Remoting HTTP.
[step10] Mise en place de Spring Remoting coté client (OSGI et sans OSGi), pour consommer les services exposés par l’application WEB.
[step11] Mise en place de Spring Remoting coté serveur, dans un bundle OSGi (application WEB classique transformée en bundle OSGi) pour exposer les services via Remoting HTTP.
[step12] Mise en place d’un client Eclipse RCP composé d’une ViewPart qui contient une Table SWT qui affiche une liste de User construite en dur dans le ViewPart. Dans ce billet nous n’utiliserons pas le service UserService qui doit être récupéré via Spring DM. PDE sera utilisé pour initialiser l’application RCP et le code généré sera décortiqué et expliqué.
[step13] Enrichissement du client Eclipse RCP composé d’une ViewPart qui fait appel au service UserService pour afficher la liste des Users. Ce client sera utilisé dans 2 architectures (Full Client et Client/Serveur). Le service UserService sera récupéré dans le ViewPart par le mécanisme d’Injection de Dépendance de Spring à l’aide de SpringExtensionFactory développée par Martin Lippert.
[step14] Introduction à la mise en place de la couche DAO pour se connecter à une base de données (H2 et Derby) via JPA (Hibrenate/EclipseLink). Dans ce billet nous téléchargerons tous les JARs requis (JPA, Base H2 et Derby, Implémentation JPA (Hibrenate, EcliseLink) pour la mise en place de la couche DAO en utilisant Maven.
[step15] Dans ce billet nous allons créer les 2 base de données H2 et Derby en créant des Scripts :
* de création de la table T_USER
* d’injection de données.
[step16] Introduction à JPA (sans Spring ni OSGi) avec 2 implémentation de JPA (Hibernate et EclipseLink) ou l’on se connectera aux 2 bases H2 et Derby.
[step17] JPA avec Spring ORM (sans OSGi) pour utiliser JPA dans un conteneur avec Spring en suivant le design pattern Service/DAO. Le bean factory Spring LocalEntityManagerFactoryBean sera utilisé pour déclarer « basiquement » l’EntityManagerFactory.
[step18] Utilisation de LocalContainerEntityManagerFactoryBean pour configurer les provider et les properties JPA via des beans Spring (et plus dans le fichier persistence.xml).
[step19] Mise en place des DAO avec JPA (EclipseLink et Hibernate) dans un contexte OSGi (avec Spring ORM) en utilisant 2 bases de données (Derby+H2).
  1. Vince
    Mai 15, 2012 à 3:31

    Salut,
    pourrais tu me dire la raison qui t’as poussé – dans cet excellente série de billets – à choisir Spring DM plutôt qu’ OSGi DS ?

    Encore merci pour ce tuto comme on en voit rarement 😉

    • Mai 15, 2012 à 5:03

      Salut Vince,

      Avec Spring DM tu beneficies de la puissance de Spring (AOP, IOC) et Spring forunit plein de support (JPA, Remoting, etc…) , c’est pour cela que Spring DM m’a attiré (aujourd’ui Spring DM est devenu Eclipse Gemini Blueprint).

      Merci de ton post.

      Angelo

  2. Pierre
    septembre 9, 2012 à 9:32

    Salut,

    J’ai passé mon WE (et j’ai pas fini !) sur cette série d’article, vraiment un excellent travail !

    J’ai une petite question : je manage mes DAO et services grâce à Spring, j’ai bien compris comment injecter un service dans une View, mais procéder à une injection du même type dans mon application (au sens RCP du terme), ou plus généralement, dans autre chose qu’une ViewPart ? Un cas d’utilisation serait par exemple un formulaire de login affiché au lancement de l’application (avant la première vue…). J’ai essayé de mettre en place un ServiceTracker, sans grand succès…

    Merci pour les article !

    • septembre 9, 2012 à 9:59

      Bonjour Pierre,

      L’injection de dépendance n’était pas vraiment un mécanisme pensé au départ dans RCP 3.x. Comme tu as pu lire dans mes articles, Martin Lippert propose une solution http://martinlippert.blogspot.fr/2008/05/dependency-injection-for-extensions.html qui marche bien mais qui se limite au composants (Editor, View) qui s’utilisent via des points d’extension avec l’attribut « class ».

      C’est pour cela que je pense qu’il est temps de passer à Eclipse E4 qui intègre un moteur d’injection et tout est géré via @Inject (services OSGi, autres…) Je suis en train d’étudier E4 et je vais essayer de faire des articles dessus.

      Angelo

  3. Pierre
    septembre 9, 2012 à 10:19

    Merci pour la réponse !

    J’ai testé un peu E4, mais j’ai peur que mon client final ne soit pas très chaud pour une mouture aussi « jeune »…

    Si je dois rester en 3.X, j’avoue que la perspective de devoir gérer « manuellement » l’accès à mes services (via singleton ?!) ne m’enchante pas plus que ça, mais je ne vois pas d’autre solution…

    J’attends avec impatience les prochains articles, ton blog est de loin la meilleure source d’information que j’ai trouvée sur ce sujet après des heures de recherche…

    Pierre

  1. décembre 7, 2009 à 1:53
  2. août 31, 2010 à 12:32
  3. juillet 23, 2011 à 9:46
  4. avril 5, 2012 à 10:11

Laisser un commentaire