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).