Catégorie: E4

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step4] nous avons utilisé le registre de services OSGi pour consommer/fournir le service UserService. Nous avons montré que l'utilisation du registre de services OSGI, permettait de rendre opérationnel le lancement/arrêt du bundle org.akrogen.gestcv.services qui fournit le service UserService :

• lorsque le bundle service org.akrogen.gestcv.services est arrêté, le bundle client org.akrogen.gestcv.simpleosgiclient qui souhaite consommer le service UserService, récupère une instance null.
  
• lorsque le bundle service org.akrogen.gestcv.services est lancé, le bundle client org.akrogen.gestcv.simpleosgiclient qui souhaite consommer le service UserService, récupère l'instance UserService fournit par le bundle services.
  

Dans ce billet je vais expliquer 2 "bonnes pratiques" à suivre dans les Bundle OSGi :

• scinder les bundles services en 2 bundles services API et Implémentation. Dans notre cas nous scinderons le bundle org.akrogen.gestcv.services en 2 bundles services API et Implémentation.
  
• favoriser la gestion des dépendances entre bundles avec Import Package au lieu de Require Bundle, qui sera expliqué plus en détail dans la section Import Package.
  

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que :

• le bundle service org.akrogen.gestcv.services est scindé en 2 bundles service API et Implémentation.
• les dépendances entres bundles sont gérées via Import Package (et plus par Require Bundle).
  

» Lire la suite!

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step3] nous avons mis en place les 3 bundles OSGi Client org.akrogen.gestcv.simpleosgiclient, Services org.akrogen.gestcv.services et Domain org.akrogen.gestcv.domain. Le service UserService est récupéré via la factory de services ServicesFactory qui est un singleton. OSGi met en avant le fait que l'on puisse lancer/stopper des bundles à chaud sans devoir arrêter le conteneur OSGi. Nous verrons dans ce billet que le lancement/arrêt de nos bundles est à ce stade obsolète et par la suite comment y remédier en utilisant le registre de services OSGi. Autrement dit ce billet aborde le registre de services OSGi en expliquant comment fournir/consommer le service UserService via ce registre. Je vous conseille de lire La plate-forme dynamique de services OSGi pour plus d'informations sur la notion de services OSGi.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que :

• le bundle client org.akrogen.gestcv.simpleosgiclient consomme toutes les 5 sec le services UserService via la Thread FindAllUsersThread.
• la factory de services ServicesFactory a disparu. L'instance service UserServive est enregistré et récupéré via le registre de services OSGi (en utilisant ServiceTracker).

Dans ce billet nous montrerons pas à pas comment nous arrivons au choix de conception décrit ci-dessus :

• Dans la section start/stop bundle, le bundle client appele via une Thread toutes les 5 sec le service UserService via la factory ServicesFactory. Nous montrerons qu'avec le singleton ServicesFactory, l'arrêt du bundle services est obsolète. Vous pouvez télécharger l'ensemble des projets expliqués dans cette section sur org.akrogen.gestcv_step4-thread.zip.
  
• Dans la section OSGi Services Registry, le bundle service et client utilisent le registre de services OSGi pour fournir/consommer le service UserService. Nous montrerons qu'avec l'utilisation du registre de services OSGi, l'arrêt du bundle service a une influence. Vous pouvez télécharger l'ensemble des projets expliqués dans cette section sur org.akrogen.gestcv_step4-osgiservicesregistry.zip.
  
• Dans la section ServiceTracker, le ServiceTracker OSGi est utilisé dans le bundle client pour consommer le service UserService enregistré (par le bundle service) dans le registre de services OSGi. Ce tracker évite de solliciter tout le temps le registre de services OSGi pour récupérer le service UserService. Vous pouvez télécharger l'ensemble des projets expliqués dans cette section sur org.akrogen.gestcv_step4-servicetracker.zip.
  

» Lire la suite!

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step2] nous avons créé le Bundle OSGi org.akrogen.gestcv.domain et préparé l'environnement OSGi (Target Platform). Dans ce billet nous allons créer les 2 Bundles OSGi Services org.akrogen.gestcv.services, et Client org.akrogen.gestcv.simpleosgiclient et gérer leur dépendances via leur fichier MANIFEST.MF.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma met en évidence plusieurs notions :

• les dépendances entre les Bundle OSGi s'effectuent via le fichier META-INF/MANIFEST.MF et plus par le Java Build Path classique.
• l'appel des services par le client ne se fait plus par un main Java mais par la méthode start du BundleActivator.

En fin du billet nous reprendrons les 2 problèmes souléves avec le Java build Path classique et qui seront résolus avec OSGi:

• Classes non protégées qui sera résolu via les export package du MANIFEST.MF.
  
• ClassLoader qui sera résolu par la fait qu'un Bundle OSGi a son propre ClassLoader.
  

Vous pouvez télécharger les projets org.akrogen.gestcv_step3.zip et org.akrogen.gestcv_step3-commons-lang.zip (zip qui contient les Bundle OSGi qui utilisent 2 versions de la librairie Apache commans-lang*.jar et qui montre en évidence le problème de ClassLoader résolu) présentés dans ce billet.

» Lire la suite!

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Dans le billet précédant [step0], j'ai présenté ce que je souhaitais effectuer dans les billets intitulés Conception d'un client Eclipse RCP et serveur OSGI avec Spring DM. Pour rappel, mon idée est d'expliquer pas à pas comment créer une application cliente eclipse RCP qui communiquera avec des services hébérgés sur un serveur OSGI. L'application RCP affichera une liste d'utilisateurs User récupérée via un service UserService qui sera hébérgé sur le serveur OSGI. Dans ce billet nous n'allons pas encore faire d'OSGI, mais nous allons créer un client (Java main) qui va communiquer avec un service UserService qui retournera une liste de User. Ce service qui est une interface sera récupéré via une factory de services ServicesFactory. Nous découperons chacune de ces couches (Client/Service/Domain (POJO User)) dans un projet Java distinct.

Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma met en évidence trois projets Java :

• org.akrogen.gestcv.domain (POJO) : projet Java qui contient les POJO (domaine de l'application) entre autres le POJO User.
• org.akrogen.gestcv.services (Services) : projet Java qui contient le service UserService qui permet de retourner une liste d'utilisateurs User.
• org.akrogen.gestcv.simplemainclient (Client) : projet Java qui consomme dans un main Java le service UserService.

Les dépendances entre les projets sont gérées classiquement via le Java Build Path du projet. Nous verrons en fin de ce billet les 2 problémes courant que nous rencontrons avec ce type de dépendance classique :

• il est impossible de rendre inaccéssible l'utilisation de certaines classes d'un projet Java aux classes d'un autre projet Java. Ce problème sera résolu via OSGI dans le prochain billet en indiquant les packages que l'on souhaite exposer.
• tous les projets Java partagent le même ClassLoader, ce qui peut poser des problèmes lorsque l'on souhaite utiliser des versions différentes d'une librairie dans les projets Java. Ce problème sera résolu via OSGI dans le prochain billet car chaque Bundle OSGI a son propre ClassLoader.

Vous pouvez télécharger les projets org.akrogen.gestcv_step1.zip et org.akrogen.gestcv_step1-commons-lang.zip (zip qui contient les projets Java qui utilisent 2 versions de la librairie Apache commans-lang*.jar et qui montre en évidence le problème de ClassLoader) présentés dans ce billet.

» Lire la suite!

Vous pouvez trouver ce billet sur mon nouveau blog avec les informations mises a jour.

Il y a 3 ans j'ai créé le projet GestCV, une application WEB de gestion de CV basé sur Spring, Hibernate, Struts1.x et AJAX. A cette époque je souhaitais utiliser et mettre en évidence toutes les technologies que j'adorais dans un véritable projet.

Aujourd'hui j'ai décidé de me former au développement d'applications Eclipse RCP basé sur les API SWT et JFace que j'ai découvert à travers le développement du plugin Eclipse Akrogen, du projet TK-UI et JFace DOM Databinding. Eclipse RCP me séduit de plus en plus pour les raisons suivantes. Avec Pascal Leclercq nous avons créé ce mois-ci le projet OSGI GestCV qui est une version RCP de GestCV (le projet est en phase d'étude). Plus exactement ce projet est basé sur une architecture client/serveur, autrement dit :

• la couche serveur fournira les services utiles pour la gestion de CV (édition d'un CV, création d'un CV).et sera basée sur OSGI via Spring DM. Les services feront appels à la base de données via Hibernate.
• la couche cliente sera une application Eclipse RCP qui consommera les services hébérgés sur le serveur.

Nous souhaitons utiliser OSGI dans la couche serveur pour démarrer/arrêter à chaud les services sans devoir redémarrer le serveur (très utile en développement comme en production). OSGI fournit d'autres avantages que je tenterais d'expliquer tout au long de ces billets. Je ne sais pas si nous aboutirons ce projet mais mon but premier est de me former aux technologies OSGI, Spring DM, RCP et de les expliquer par des exemples concrets et détaillés dans des billets.

Mon idée est de rédiger des billets qui expliqueront pas à pas comment réaliser une application Eclipse RCP qui communique avec un serveur OSGI avec Spring DM. Concrètement je vais tenter d'expliquer comment développer une petite application RCP qui affiche/met à jour une liste d'utilisateurs récupérée par des services (OSGI) hébérgés sur le serveur. Je tenterais en même temps d'expliquer l'interêt d'OSGI.

Nous avons aussi envisagé d'étudier plus tard (selon notre temps) ce que peut nous fournir le futur projet Eclipse E4 (moteur CSS (qui est à l'origine celui de projet TK-UI ), Modeled Workbench, SWT Flex...) et RAP (qui d'après ce que j'ai compris permet de déployer l'application RCP en mode WEB ).

Si le sujet vous intéresse, vous pouvez commencer par lire le billet [step1] de la série de billets intitulée Conception d'un client Eclipse RCP et serveur OSGI avec Spring DM .

» Lire la suite!

Eclipse E4 est la futur version d'Eclipse qui couvre plusieurs problématiques :

• Declarative UI :
  ceci permettra de déclarer les Interfaces Utilisateur (Workbench, Perspectives, Wizards, Vues, Widgets (Text, Label, Combo...)) à l'aide d'un langage XML par exemple (XUL, XHTML, XAML...).
  Eclipse E4 semble étudier la solution d'utiliser EMF qui permet de modéliser ses interfaces et de les manipuler avec une hiérarchie d'Objets Java. Le résultat peut être persisté dans un fichier XML (au format XMI).
• CSS Styling : ceci permettra d'utiliser des feuilles de styles CSS pour styler les Widgets (color, font, cursor...) des Interfaces Utilisateur du workbench Eclipse.
• Scripting : ceci permettra de gérer le workbench Eclipse à l'aide de scripts.

» Lire la suite!

Après avoir été exclusivement une plateforme de développement, ou un EDI (Environnement de développement Intégré), Eclipse s'est transformé au fils des versions en une plateforme pour clients riches (RCP), et est même en train d'être utilisée dans des applications de type serveur, comme par exemple l'utilisation de son conteneur OSGi Equinox comme noyau du serveur SpringSource Spring DM Server.

» Lire la suite!