Voila ca sera mon dernier billet sur le blog Akrogen de DVP. J'ai décidé pour des raisons techniques de passer sur wordpress (c'est surout pour la coloration syntaxique du code Java, XML que j'ai decide de changer de blogs sur wordpress).

Je ne vais pas détruire ce blog et laisser tous les billets mais j'ai migre tous les billets intitulés Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step*] sur wordpress.

Je remercie encore DVP pour m'avoir fourni ce blog qui m'a beaucoup aidé à rencontrer plein de personnes passionnées.

URL du nouveau blog : http://angelozerr.wordpress.com/

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 [step1] nous avons mis en place les 3 couches Client/Services/Domaine dans 3 projets Java qui font références entre eux avec le classique Java Build Path. Nous avons vu que ce type de dépendance engendrait les 2 problèmes de classes non protégées et de ClassLoader. Dans ce billet nous allons créer et lancer notre premier Bundle OSGi, autrement dit nous allons transformer le projet Java org.akrogen.gestcv.domain en Bundle OSGi et préparer l'environnement OSGI (Target Platform). Dans le prochain billet nous transformerons les 2 autres projets Java en Bundle OSGi et verrons comment OSGi règle les 2 problèmes cités en introduction.

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

Ce schéma met en évidence plusieurs notions :

• Bundle OSGi : le projet Java org.akrogen.gestcv.domain devient un Bundle OSGi qui est un projet Eclipse Plug-in.
  
• Target Platform : ensemble de Bundles OSGi (JARs) nécéssaires au Bundle OSGi que nous créons dans le workspace Eclipse. Dans notre cas nous allons dépendre du Bundle OSGi org.eclipse.osgi qui contient l'API OSGi.
  
• Conteneur OSGi (Equinox) : hébérge et orchestre les Bundles OSGi (gère leur cycle de vie) provenant de notre workspace Eclipse et de la Target Platform. Nous utiliserons Equinox qui est celui par défaut utilisé par Eclipse.
• Dependances : les dépendances entre les Bundle OSGi s'effectuent via le fichier META-INF/MANIFEST.MF et plus par le Java Build Path classique.
• BundleActivator (classe Activator) : permet d'éxecuter du code lors du lancement/arrêt du Bundle.

Nous nous appuierons sur l'ensemble de plugins PDE (Plug-in Development Environment) qui permet de créer des Plug-ins Eclipse mais aussi des Bundles OSGI (un Plug-in Eclipse est en fait un Bundle OSGI).

Vous pouvez télécharger les projets org.akrogen.gestcv_step2.zip 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!

A l'étape du billet précédant [step18] nous avons mis en place les fonctionnalité de suppression de state, d'actions et connections dans la page Graphics GEF. A ce stade nous avons des outils de la palette GEF et des actions GEF qui permettent de mettre à jour le modèle EMF via des Command GEF. Plus exactement ce sont les EditPolciy installés sur chacun des EditPart GEF qui réagissent aux outils/actions et qui interprètent les Request GEF en Command GEF. Les EditPolicy pourrait mettre à jour directement le modlèle EMF sans passer par des Command GEF. Pourquoi utiliser des Command GEF? L'editor GEF GaaphicalEditor gère en interne une stack de Command GEF (GraphicalEditor#getEditDomain()#getCommandStack()) qui dépile/empile les Command GEF executées dans l'editor via les outils des palettes et les Actions GEF.

Cette stack de Command GEF permet de gérer le undo/redo dans l'editor GEF en appelant pour chaque action GEF UndoAction/RedoAction la méthode Command#undo()/redo() de la dernière Command GEF exécutée. A ce stade nous n'avons pas implémentées ces 2 méthodes dans nos Command GEF. Dans ce billet nous allons les implémenter pour gérer le undo/redo :

• après avoir ajouté un state/action via l'outil de création de state/action en implémentant les méthodes undo/redo de la command GEF CreateCommand
• après avoir créé une connection entre un state/action via l'outil de création de connections en implémentant les méthodes undo/redo de la command GEF ConnectionCreateCommand
• après avoir supprimé un state/action via l'action GEF DeleteAction en implémentant les méthodes undo/redo de la command GEF DeleteCommand
• après avoir supprimé une connection via l'action GEF DeleteAction en implémentant les méthodes undo/redo de la command GEF DeleteConnectionCommand

Les fonctionnalités undo/redo seront accéssibles via :

• le menu contextuel de la page GEF Graphics avec les entrée de menu "Undo" et "Redo".
• le menu global "Edit" avec les entrée de menu "Undo" et "Redo".
• la combinaison de touches "Ctrl+Z" et "Ctrl+Y"

Vous pouvez télécharger le projet org.example.workflow_step19.zip présenté dans ce billet.

» Lire la suite!

A l'étape du billet précédant [step17] nous avons réglé le problème de la selection d'un EditPart GEF. Si vous mettez un point d'arrêt dans la méthode GraphicalEditor#selectionChanged(IWorkbenchPart part, ISelection selection), puis si vous sélectionnez un state, action de la page GEF Graphics vous pourrez constater que cette méthode est appelée :

public void selectionChanged(IWorkbenchPart part, ISelection selection) { 
  // If not the active editor, ignore selection changed. 
  if (this.equals(getSite().getPage().getActiveEditor())) 
    updateActions(selectionActions); 
}

Mais la méthode updateActions n'est jamais appelé. Nous expliquerons dans ce billet comment régler ce problème pour pouvoir ensuite implémenter les fonctionnalités de suppression :

• suppression des states/actions sélectionnés.
• suppression des connections sélectionnées.

La supppression pourra s'effectuer via :

• l'entrée de menu "Delete" accessible par le menu contextuel de la page GEF Graphics.
• la touche "Suppr".
• l'entrée de menu "Delete" accessible par le menu global "Edit".

Voici une copie d'écran qui affiche le menu contextuel qui permettra de supprimer un state sélectionné :

Vous pouvez télécharger le projet org.example.workflow_step18.zip présenté dans ce billet.

» Lire la suite!

A l'étape du billet précédant [step16] nous avons finalisé la palette d'outils GEF qui permet de créer des states, des actions et des connections entre actions et states.

Dans ce billet je souhaitais dans un premier temps expliquer comment mettre en place la fonctionnalité "suppression de state, actions, connections" dans la page GEF Graphics, à l'aide de la touche "Suppr" ou à l'aide d'une action d'un menu contextuel. Je me suis inspiré des exemples GEF qui sont basés sur un EditorPart simple (une seule page GEF) pour intégrer cette fonctionnalité de delete dans notre editor multi page de workflow (MultiPageEditorPart) et je me suis rendu compte que nous ne pouvions pas encore mettre en place cette fonctionnalité de delete avant d'avoir régler le problème de sélection des EditPart GEF (pour ensuite les supprimer avec l'action delete). La selection d'EditPart GEF ne fonctionne pas dans notre cas car :

1. le code générée par EMF concernant la sélection d'items (ISelectionProvider) dans l'editor multi page WorkflowEditor obstrue la selection d'un item provenant d'une autre page non générée par EMF (qui n'utilise pas ViewerPane EMF). Par exemple, dans le cas de notre editor GEF la selection d'un EditPart GEF est obstruée. Pour plus d'informations sur ce sujet, voir la section GEF GraphicalViewer - ISelectionProvider.
   
2. nous sommes dans un contexte de multi page et que l'editor GEF org.eclipse.gef.ui.parts.GraphicalEditor ne fonctionne pas dans un multi page concernant le sujet de la selection d'EditPart. Nous réglerons ce problème dans le prochain billet.

Pour mettre en évidence le premier problème, mettez un point d'arrêt dans la méthode GraphicalEditor#selectionChanged(IWorkbenchPart part, ISelection selection), sélectionnez un state, action de la page GEF Graphics et vous pourrez constater que cette méthode n'est jamais appelé :

public void selectionChanged(IWorkbenchPart part, ISelection selection) { 
  // If not the active editor, ignore selection changed. 
  if (this.equals(getSite().getPage().getActiveEditor())) 
    updateActions(selectionActions); 
}

Nous expliquerons dans le prochain billet l'importance de ce code qui réagit à la selection des EditPart GEF, et qui permet de gérer les actions de delete des EditPart GEF sélectionné.

Pour expliquer le 2ème problème, il faut que le premier soit résolu et mettez ensuite un point d'arrêt à la fin de la méthode GraphicalEditor#selectionChanged(IWorkbenchPart part, ISelection selection) ( appel de updateActions) et vous pourrez constater que le point d'arrêt ne s'arrête jamais.

Pour résoudre le premier problème, je me suis appuyé sur l'excellent article Integrating EMF and GMF Generated Editors qui explique pas à pas comment intégrer un editor GEF généré par Graphical Modeling Framework (GMF) dans un multi page editor généré par EMF.

A la fin de ce billet, lorsque nous sélectionnerons un state, action, connection, cette sélection s'affichera dans la barre de statut (ce qui à ce stade ne fonctionne pas).

Vous pouvez télécharger le projet org.example.workflow_step17.zip présenté dans ce billet.

» Lire la suite!

A l'étape du billet précédant [step15] nous avons mis en place la palette GEF qui contient les 2 outils de création de state et d'actions. Dans ce billet nous allons ajouter l'outil de création de connections qui permettra à partir de la palette GEF de connecter les actions aux states :

Vous pouvez télécharger le projet org.example.workflow_step16.zip présenté dans ce billet.

» Lire la suite!

A l'étape du billet précédant [step14] nous avons mis en place le layout automatique et finalisé la partie GEF traitant la représentation graphique du workflow XML. A partir de maintenant nous allons nous concentrer sur les fonctionnalités d'édition GEF (palette d'outils, intéraction avec le clavier (Ctrl+Z..)). Dans ce billet nous allons mettre en place la palette GEF qui proposera 2 outils :

• un outil de création de states qui permettra à partir de cette palette d'ajouter un modèle EMF StateType au modèle EMF WorkflowType.
  
• un outil de création d'actions qui permettra à partir de cette palette d'ajouter un modèle EMF ActionType au modèle EMF WorkflowType.
  

Voici une copie d'écran ou le state "s3" a été ajouté via l'outil de création de states :

Vous pouvez télécharger le projet org.example.workflow_step15.zip présenté dans ce billet.

» Lire la suite!