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

Services & version bundle

Livraison & Bugs

Ici nous allons décrire un scénario classique de livraison d’une application. L’application livrée est installée et tous les utilisateurs se connectent dessus. Malheureusement le distribuable contient un service qui est buggé.

JEE – WAR, EAR

Dans le cas de JEE, un distribuable est sous forme de WAR et EAR, et ceci pose les problèmes suivants :

• la correction du bug engendre la livraison d’un nouveau distribuable WAR ou EAR. Autrement dit l’ensemble de l’application doit être relivrée. Il n’est pas possible de livrer un petit distribuable qui contiendrait uniquement la partie service corrigée. Packager un EAR peut devenir extrèmement long et coûteux ce qui rend la correction d’un EAR buggé extrêmement lente (éventuellement plusieurs jours).
• l’installation du nouveau distribuable est tres lourde et engendre l’arrêt du serveur. Tous les utilisateurs seront pénalisés uniquement pour corriger l’utilisation d’un service (et il se peut que la plupart des utilisateurs n’y aient même pas accès).

OSGi – JAR

Dans le cas de OSGi, un distribuable est sous forme de un ou plusieurs JAR par Bundle OSGi :

• La livraison d’un JAR (Bundle) peut suffire pour corriger le problème.
• l’installation du nouveau distribuable (JAR) est très légère (elle s’effectue via la console OSGi par la commande install) et peut s’effectuer à chaud. Ce « patch » est transparent pour les utilisateurs connectés.

Un Bundle OSGi est identifié par son ID (Bundle-SymbolicName) et sa version (Bundle-Version). Le « patch » à livrer consiste à créer un bundle qui corrige le bug (du service) en incrémentant sa version. Il est ensuite possible de lancer un même Bundle (même ID Bundle-SymbolicName) avec des versions différentes. C’est que je souhaite montrer dans cette section.

Bug UserService

Nous allons simuler une erreur dans le service UserServiceImpl du Bundle org.akrogen.gestcv.services de version 1.0.0.qualified et créer un nouveau bundle « patch » org.akrogen.gestcv.services de version 1.0.1.qualified qui corrige le problème. Nous verrons qu’avec notre architecture, note bundle « patch » ne fonctionnera pas, car nous devons scinder le Bundle org.akrogen.gestcv.services en 2 bundles services API et Implémentation.

Vous pouvez télécharger l’ensemble des projets expliqués dans cette section sur org.akrogen.gestcv_step5-patch.zip. Nous allons partir des projets du billet précédant org.akrogen.gestcv_step4-servicetracker.zip.

org.akrogen.gestcv.services (1.0.1)

Ici nous allons créer le bundle « patch » org.akrogen.gestcv.services de version 1.0.1. Pour cela :

• Copiez le projet org.akrogen.gestcv.services et nommez le org.akrogen.gestcv.services_patch.
• Modifier la version du bundle en 1.0.1.qualifier dans le MANIFEST.MF :
  Bundle-Version: 1.0.1.qualifier

org.akrogen.gestcv.services (1.0.0)

Ici nous allons modifier le bundle org.akrogen.gestcv.services de version 1.0.0 pour simuler un bug dans la classe org.akrogen.gestcv.services.impl.UserServiceImpl. Pour cela, modifiez cette dernière comme suit :

Relancez (via GestCV OSGi ) Equinox et la console OSGi affiche :

Cette trace montre que les 2 bundles org.akrogen.gestcv.services de version différente ont été lancée. Elle montre que le service UserService est consommée, ce qui signifie que c’est le bundle de version 1.0.1 qui a pris la main.

Tappez ss pour afficher la liste des bundles et leur ID :

Nous allons maintenant arrêter le bundle org.akrogen.gestcv.services de version 1.0.1. Pour cela tapez dans la console OSGi stop 38 :

Cette trace montre que le service UserService n’est plus disponible. Le bundle org.akrogen.gestcv.services de version 1.0.1 étant stoppé, il ne fournit plus le service UserService. Cependant le bundle (avec le bug) org.akrogen.gestcv.services de version 1.0.0 est activé et on s’attend à ce que le service soit fournit par ce bundle. Mais ceci ne fonctionne pas? Je pense que le problème vient du fait que l’interface UserService est contenu dans les 2 versions des bundles org.akrogen.gestcv.services, ce qui au passage n’est pas très propre. Pour résoudre le problème, nous allons scinder le bundle org.akrogen.gestcv.services en 2 bundles services API et Implémentation.

Bundle Services API/Implémentation

Jusqu’a maintenant le bundle org.akrogen.gestcv.services contient :

• l’API de services représenté par l’interface UserService.
• l’implémentation de l’API de services UserServiceImpl.

A ce stade l’API et l’implémentation de services sont stockés dans le même bundle et ce choix de conception est contraignant :

• impossible de faire cohabiter plusieurs bundles org.akrogen.gestcv.services de différentes versions (voir explication ci-dessus).
• le cycle de vie de l’interface UserService et de l’implémentation UserServiceImpl peuvent être différent (ex : la correction d’un bug de la classe UsertServiceImpl nécessite la création du bundle services avec une nouvelle version alors que l’interface UserService ne bouge pas).
• un intérêt de découpler les bundles API et implémentation est de permettre de fournir plusieurs implémentations d’une même API. En effet avec l’utilisation du registry de services OSGi un autre bundle peut ajouter une autre implémentation du service UserService. Ce bundle pour fonctionner doit être lié au bundle actuel org.akrogen.gestcv.services qui fournit l’API des services, mais qui enregistre aussi l’implémentation UserServicesImpl. Il n’est donc pas possible d’utiliser l’implémentation du service UserService de ce bundle sans devoir arrêter le bundle org.akrogen.gestcv.services (pour désenregsitrer UserServiceImpl) ou faire un filtre sur le service lors de sa récupération par le bundle client.

En règle général, il est conseillé de séparer l’API Services et son Implémentation en 2 bundles distincts. Nous allons dans notre cas

• modifier le bundle org.akrogen.gestcv.services pour qu’il ne contienne que l’interface UserService (API)
• créer un nouveau bundle org.akrogen.gestcv.services.impl qui contiendra l’implémentation UserServiceImpl et qui enregsitrera cette instance dans le registre de services OSGi via ServiceTracker.

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

Ce schéma met en évidence les 2 bundles Services API org.akrogen.gestcv.services et Implémentation.

Vous pouvez télécharger org.akrogen.gestcv_step5-api-services-bundle.zip qui contient le code expliqué ci-dessous. Nous allons partir des projets du billet précédant org.akrogen.gestcv_step4-servicetracker.zip.
org.akrogen.gestcv.services.impl .

Implémentation – org.akrogen.gestcv.services.impl

Ici nous allons créer le bundle org.akrogen.gestcv.services.impl, bundle d’implémentation de services. Pour cela :

• copiez le projet org.akrogen.gestcv.services et nommez le nouveau projet org.akrogen.gestcv.services.impl.
• Modifiez le Bundle-SymbolicName du MANIFEST.MF avec org.akrogen.gestcv.services.impl :
  Bundle-SymbolicName: org.akrogen.gestcv.services.impl
• Supprimez l’interface org.akrogen.gestcv.services.UserService.
• le bundle d’implémentation de services ne doit d’exposer aucun package (car il s’occupe d’enregistrer l’implémentation de services UserServiceImpl dans le registre de services OSGi). Pour cela, supprimez dans le MANIFEST.MF, la section
  Export-Package: org.akrogen.gestcv.services
• le bundle doit faire référence au bundle domain et services API. Pour cela modifiez le MANIFEST.MF avec Require-Bundle :
  Require-Bundle: org.akrogen.gestcv.domain;bundle-version="1.0.0",
   org.akrogen.gestcv.services;bundle-version="1.0.0"

API – org.akrogen.gestcv.services

Ici nous allons modifier le bundle org.akrogen.gestcv.services, bundle d’API de services. Pour cela :

• Supprimer la classe ServicesFactory.
• Supprimer la classe UserServiceImpl.
• Supprimer l’enregistrement du service dans l’Activator ce qui donne :
  package org.akrogen.gestcv.services.internal;
   
  import org.osgi.framework.BundleActivator;
  import org.osgi.framework.BundleContext;
   
  public class Activator implements BundleActivator {
   
    public void start(BundleContext context) throws Exception {
      System.out.println("Start Bundle ["
          + context.getBundle().getSymbolicName() + "]");
    }
   
    public void stop(BundleContext context) throws Exception {
      System.out.println("Stop Bundle ["
          + context.getBundle().getSymbolicName() + "]");
    }
   
  }

Relancez (via GestCV OSGi ) Equinox et la console OSGi affiche :

Cette trace montre que les 4 bundles sont lances dont les bundles API et Implémentation services. La consommation du service UserService s’effectue ensuite correctement par le bundle client.

Services Impl& version bundle

Maintenant que nous avons 2 bundles services API et Implémentation, nous allons recommencer notre test avec nos bundles services buggués et patchés en repartant des projets org.akrogen.gestcv_step5-api-services-bundle.zip. Vous pouvez télécharger org.akrogen.gestcv_step5-api-services-bundle-patch.zip qui contient le code expliqué ci-dessous.

org.akrogen.gestcv.services.impl (1.0.1)

• Copiez le projet org.akrogen.gestcv.services.impl et nommez le org.akrogen.gestcv.services.impl_patch.
• Modifier la version du bundle en 1.0.1.qualifier dans le MANIFEST.MF :
  Bundle-Version: 1.0.1.qualifier

org.akrogen.gestcv.services.impl (1.0.0)

Modifiez la classe UserServiceImpl comme ceci :

Relancez (via GestCV OSGi ) Equinox et la console OSGi affiche une exception toutes les 5 sec en appelant UserService :

Ceci permet d’affirmer que le bundle (qui est buggé) de version 1.0.0.qualifier est utilisé.

Tappez ss :

Ceci montre que les 2 bundles services sont lancés en même temps et qu’il est possible de faire cohabiter plusieurs versions de bundles. Le bundle de version 1.0.0.qualifier est utilisé car il est lancé avant celui de version 1.0.1.qualifier. L’ordre de lancement des bundles est important. Le conteneur OSGi n’utilise pas l’information « version » pour savoir quel bundle doit être utilisé en priorité.

Arrêter le bundle de version 1.0.0.qualifier avec la commande (dans mon cas) stop 39. La console OSGi affiche :

Cette trace permet d’affirmer que le bundle services patch (version 1.0.1) est maintenant utilisé. Ce scénario permet de montrer comment il est facile de fournir un livrable unitaire (bundle) et de l’installer sans perturber les utilisateurs connectés à l’application. L’arrêt/stop de bundles est extrêmement intéresant :

• en développement dans le cas d’une grosse application qui mets un temps (parfois considérable) à démarrer. En effet avec OSGi, cela ne nécéssite pas de redémarrer le serveur pour tester uniquement le service en cours de développement.
• en production dans le cas d’une livraison d’un distribuable qui corrigerait un bug (comme ce que nous avons expliqué ci-dessus) et qui évite de pénaliser toute les utilisateurs connectés sur l’application.

Import package vs Require Bundle

Il existe plusieurs manières de gérer les dépendances entre les bundles OSGi dont :

• Require Bundle. ce type de dépendance est lié à un bundle donné. Elle permet ensuite d’utiliser tous les packages exportès du bundle dans le bundle qui y fait référence. C’est ce type de dépendance utilisé dans les Plugin Eclipses.
• Import Package : ce type de dépendance n’est pas lié à un bundle donné. Elle permet d’indiquer que l’on souhaite utiliser les classes stockés dans un package donné. Ce package donné est un package exporté par un bundle dont on ne connait pas son existence.

OSGi préconnise d’utiliser Import Package pour ne pas lier fortement les bundles entre eux. Ce type de dépendance permet ensuite de scinder un bundle A en plusieurs bundles (A1, A2, etc) sans que les autres bundles qui étaient lié à A soient impactés. Il existe cependant 2 inconvéniants avec Import Package par rapport à Require Bundle :

• les packages doivent être importés explicitement. Si un bundle que l’on souhaite dépendre expose un nombre considérable de packages, ceci nécéssitera d’importer un à un les packages alors qu’avec Require Bundle le problème ne se pose pas.
• split package : si 2 bundles exportent 2 packages identiques, rien ne garantit que le bundle qui importe le package utilise la classe que l’on attend.

Pour éviter les 2 problèmes avec Import Package, les Plugin Eclipse utilisent Require Bundle car il n’y a aucune maîtrise des plugins qui sont lancés (on peut ajouter ses propres plugins avec n’importe quel package). Nous avons utilisé jusqu’à maintenant le type de dépendance Require Bundle que nous allons supprimer pour utiliser Import Package (nous maitrisons le choix des bundles à lancer). Vous pouvez télécharger org.akrogen.gestcv_step5-import-package.zip qui contient le code expliqué ci-dessous :

• Bundle org.akrogen.gestcv.services:
  • Supprimmez la dépendances au bundle org.akrogen.gestcv.domain en supprimant la méta donnée Require-Bundle du MANIFEST.MF.
  • Importer le package org.akrogen.gestcv.domain :
    Import-Package: org.akrogen.gestcv.domain,
     org.osgi.framework;version="1.3.0"
• Bundle org.akrogen.gestcv.services.impl:
  • Supprimmez les dépendances les 2 bundles org.akrogen.gestcv.domain et org.akrogen.gestcv.services en supprimant la méta donnée Require-Bundle du MANIFEST.MF.
  • Importer le package org.akrogen.gestcv.domain et org.akrogen.gestcv.services:
    Import-Package: org.akrogen.gestcv.domain,
     org.akrogen.gestcv.services,
     org.osgi.framework;version="1.3.0"
• Bundle org.akrogen.gestcv.simpleosgiclient:
  • Supprimmez les dépendances les 2 bundles org.akrogen.gestcv.domain et org.akrogen.gestcv.services en supprimant la méta donnée Require-Bundle du MANIFEST.MF.
  • Importer le package org.akrogen.gestcv.domain et org.akrogen.gestcv.services:
    Import-Package: org.akrogen.gestcv.domain,
     org.akrogen.gestcv.services,
     org.osgi.framework;version="1.3.0",
     org.osgi.util.tracker;version="1.4.2"

Conclusion

Dans ce billet nous avons mis en évidence et montrer l’interêt d’utiliser le registre de services OSGi (pour arrêter/stopper les bundles). Dans le prochain billet nous montrerons l’interêt d’utiliser Spring et plus particulièrement Spring DM pour pouvoir déclarer les services que l’on souhaite fournir/consommer via le registre de services OSGi.

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.

start/stop bundle

Avec OSGi, il est possible de lancer/stopper (commande start/stop), installer/désinstaller (commande install/uninstall) des bundles. A mes débuts d’OSGi je pensais par exemple que l’arrêt (ou la désinstallation) d’un bundle déchargeait les classes et que l’on pouvait ainsi arrêter n’importe quel bundle. Mais ce n’est pas le cas et nous allons montrer par l’exemple ci dessous que l’arrêt ou la desinstallation d’un bundle n’a aucun effet avec notre architecture mise en place à ce stade.

Dans cette section, le bundle client org.akrogen.gestcv.simpleosgiclient va afficher toutes les 5 secondes dans la console OSGi, la liste de Users via le service UserService récupérer par la factory ServicesFactory. Nous verrons que l’arrêt ou la désinstallation du bundle service org.akrogen.gestcv.services n’aurra aucun effet une fois qu’il est lancé (la liste des Users continuera à s’afficher). Vous pouvez télécharger org.akrogen.gestcv_step4-thread.zip qui contient le code expliqué ci-dessous.

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

Ce schéma montre que :

• l’appel de de UserService #findAllUsers() s’effectue via la Thread org.akrogen.gestcv.simpleosgiclient.internal.FindAllUsersThread. Cette Thread appelera toutes les 5 sec le service.
• cette Thread est initialisée et lancée (FindAllUsersThread#start()) dans la méthode start du BundleActivator.
• cette Thread est arrétée (FindAllUsersThread#interrupt()) dans la méthode stop du BundleActivator.

Nous utilisons une Thread pour appeler le service UserService car si nous avions appelé directement le service UserService toutes les 5 sec dans la méthode start du BundleActivator, le bundle serait resté toujours à l’état start.

FindAllUsersThread/ServicesFactory

Créez la classe org.akrogen.gestcv.simpleosgiclient.internal.FindAllUsersThread comme suit :

Dans ce cas ci le service UserService est récupéré par la factory ServicesFactory :

ServicesFactory.getInstance().getUserService()

Activator client – FindAllUsersThread/ServicesFactory

Ici nous allons initialiser et lancer la Thread FindAllUsersThread dans le BundleActivator client. pour cela, modifiez la classe org.akrogen.gestcv.simpleosgiclient.internal.Activator comme suit :

Relancez (via GestCV OSGi ) Equinox et la console OSGi doit afficher toutes les 5 sec ceci :

Tappez ss (Short Status) dans la console pour afficher les ID des bundles, la console affiche :

Ici le bundle service org.akrogen.gestcv.services_1.0.0.qualifier est associé à l’ID 4. Stoppez ce bundle en saisissant dans la console stop 4, la console affiche :

Pour vérifier que le bundle service est bien arrêté, tappez ss, la console affiche :

Le bundle org.akrogen.gestcv.services_1.0.0.qualifier est à l’éta RESOLVED, ce qui signifie qu’il n’est pas démarré. Cependant la console OSGi continue à afficher la liste des User toutes les 5 sec, alors que le bundle service est arrêté.

Désinstaller org.akrogen.gestcv.services via la commande uninstall 4. Pour vérifier que le bundle service est bien désinstallé, tappez ss, et vous verrez que le bundle ne s’affiche plus dans la liste.

La console OSGi continue à afficher la liste des User toutes les 5 sec, alors que le bundle service est désinstallé. Ceci montre bien que les commandes stop et uninstall ne décharge pas les classes. Mais à quoi sert les commandes start/stop et install/uninstall?

OSGi Services Registry

A ce stade notre service est récupéré via le singleton ServicesFactory qui rend obsolète l’arrêt ou la désinstallation du bundle services dans lequel il est. OSGi propose un mécanisme de registre de services OSGi ou n’importe quel bundle peut enregistrer (fournir) un service et n’importe quel bundle peut récupérer (consommer) un service. Grossièrement le registre de services OSGi peut être comparé à une Map dans laquelle on peut enregistrer/retrouver un service via un identifiant (généralement le nom de l’interface du service). Les services qui sont enregistrés dans le registre de services OSGi est une classe Java classique.

Dans cette section nous allons utiliser ce registre de services OSGi pour enregistrer l’instance UserServiceImpl avec comme identifiant le nom de l’interface qu’elle implémente UserService.class.getName(). Nous verrons ensuite les avantages d’utiliser ce registre de services OSGi au lieu du singleton ServicesFactory. Spring DM utilise d’ailleurs ce registre de services OSGi pour enregistrer des services déclarés dans un fichier XML spring. Vous pouvez télécharger org.akrogen.gestcv_step4-osgiservicesregistry.zip qui contient le code expliqué ci-dessous.

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

Ce schéma montre que :

• le bundle services joue le rôle de fournisseur de services en enregistrant son instance UserServiceImpl dans le registre de services OSGi.
• le bundle client joue le rôle de consommateur de services en récupérant le service UserService enregistré dans le registre de services OSGi.
• la classe ServicesFactory n’est plus exposée.

Founisseur de services

Dans le bundle services org.akrogen.gestcv.services, la classe ServicesFactory à ce stade est accéssible par n’importe quel bundle pour pouvoir récupérer une instance de UserService. En utilisant le registre de services OSGi, cette classe ne doit plus être accéssible. Pour cela, déplacer la classe ServicesFactory dans le package org.akrogen.gestcv.services.internal.

Nous allons ensuite enregistrer l’instance UserServiceImpl dans le registre de services OSGi via l’identifiant UserService.class.getName(). Pour cela, modifiez la classe org.akrogen.gestcv.services.internal.Activator comme suit :

Consommateur de services

Dans le bundle client org.akrogen.gestcv.simpleosgiclient, nous devons récupérer le service UserService dans le registre de services OSGi via l’identifiant UserService.class.getName(). Pour cela, modifiez la méthode start de la classe org.akrogen.gestcv.services.internal.Activator comme suit :

Relancez (via GestCV OSGi ) Equinox et la console OSGi affiche ceci :

Cette trace montre que le services UserService a bien été consommé par le bundle client.

start/stop bundle – OSGi Services Registry

Ici nous allons ré-utiliser la Thread FindAllUsersThread pour consommer le service UserService récupéré toutes les 5 sec du registre de services OSGi.

FindAllUsersThread – OSGi Services Registry

Nous allons modifier la Thread FindAllUsersThread pour qu’elle recherche l’instance UserService dans le registry de services OSGi. Pour cela modifiez la classe org.akrogen.gestcv.simpleosgiclient.internal.FindAllUsersThread comme suit :

La Thread attend dans son constructeur le contexte du Bundle :

qui est ensuite utilisé pour rechercher le service :

ServiceReference ref = context.getServiceReference(UserService.class.getName());

Activator client – FindAllUsersThread/OSGi Services Registry

Modifiez dans le bundle client, la classe org.akrogen.gestcv.simpleosgiclient.internal.Activator pour utiliser la Thread FindAllUsersThread et lui passer le contexte du Bundle :

Relancez (via GestCV OSGi ) Equinox et la console OSGi affiche ceci toutes les 5 sec :

Ceci montre que le service UserService est appelé toutes les 5 sec. Arrêter le bundle services via la commande stop 4. La console OSGi affiche ceci toutes les 5 sec :

Relancez le bundle services via la commande start 4, la console OSGi réaffiche a nouveau la liste de Users :

Ici nous avons montré que l’utilisation du registre de services OSGi permet de rendre opérationnel le lancement/arrêt du bundle services. Autrement dit si ce bundle est arrêté, le service UserService n’est plus disponible et si il est à nouveau lancé, le service UserService redevient disponible.

ServiceTracker

Il est aussi possible de récupérer un service via le ServiceTracker d’OSGi. Je ne vais pas rentrer dans le détail de cette classe, mais l’idée de celle-ci est qu’elle est capable de surveiller les enregistrements/désenregistrements d’un service donné. Cette classe permet d’éviter de solliciter le registre de service OSGi pour récupérer un service comme ce que nous avons fait avant :

Avec le ServiceTracker, il faut l’initialiser comme ceci :

Puis pour récupérer le service UserService (que nous effectuons dans la Thread) il faut faire :

Vous pouvez télécharger org.akrogen.gestcv_step4-servicetracker.zip qui contient le code expliqué ci-dessous.

Activator – ServiceTracker

Dans le bundle org.akrogen.gestcv.simpleosgiclient, importez le package org.osgi.util.tracker. Le MANIFEST.MF doit avoir son Import-Package comme suit :

Modifiez la classe org.akrogen.gestcv.simpleosgiclient.internal.Activator pour initialiser un ServiceTracker sur UserService et passer l’instance ServiceTracker dans la Thread FindAllUsersThread :

FindAllUsersThread – ServiceTracker

Modifiez la classe org.akrogen.gestcv.simpleosgiclient.internal.FindAllUsersThread pour utiliser le ServiceTracker (au lieu du BundleContext) pour récupérer le service UserService :

La Thread attend dans son constructeur l’instance ServiceTracker :

qui est ensuite utilisé pour rechercher le service :

UserService userService = (UserService) userServiceTracker.getService();

Relancez (via GestCV OSGi ) Equinox et la console OSGi doit afficher ceci :

qui montre que le service est récupéré dans le registre de services OSGi via le ServiceTracker.

Conclusion

Dans ce billet nous avons montrer comment consommer/fournir le service UserService via le registre de services OSGi avec ServiceTracker. Utiliser le registre de services OSGi permet ensuite de bénéficier du lancement/arrêt des bundles à chaud (sans devoir redémarrer le conteneur OSGi). Cette fonctionnalité est très intéressante, car elle permet par exemple d’installer et lancer un bundle « patch » qui corrigerait un bundle buggé sans devoir stopper le conteneur OSGi. Je souhaitais dans un premier temps montrer en évidence ce scénario, mais l’architecture actuelle de nos bundles ne le permet pas, car le bundle org.akrogen.gestcv.services doit être scindé en 2 bundles API et Implémentation que nous expliquerons dans le prochain billet.

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.

org.akrogen.gestcv.services

Ici nous allons transformer le projet Java classique org.akrogen.gestcv.services en Bundle OSGi. Les sources Java de notre Bundle seront identiques à celui du projet Java classique. Créez le Bundle org.akrogen.gestcv.services avec les paramètres suivants :

• champs ID: org.akrogen.gestcv.services
• champs Version: 1.0.0.qualifier.
• champs Name: GestCV Services
• champs Provider: Akrogen
• champs Execution Environment: J2SE-1.5.
• option generate an activator, a Java class that controls the plug-in’s life cycle cochée.
• Activator : org.akrogen.gestcv.services.Activator

Ajoutez la dépendance (avec Require-Bundle) au Bundle org.akrogen.gestcv.domain

Sauvegardez et vous pourrez vérifier que dans le MANIFEST.MF, il y a la dépendance Require-Bundle :

Require-Bundle: org.akrogen.gestcv.domain;bundle-version="1.0.0"

Créez l’interface org.akrogen.gestcv.services.UserService comme suit :

Ce code ne compile pas car il n’arrive pas à résoudre la classe org.akrogen.gestcv.domain.User. Nous avons pourtant mis une dépendance sur le Bundle org.akrogen.gestcv.domain via Require-Bundle. Ceci s’explique par le fait que le Bundle org.akrogen.gestcv.domain n’expose aucune classes et que par conséquent la classe org.akrogen.gestcv.domain.User n’est pas accéssible. En effet par défaut un Bundle n’expose aucune classes. Pour indiquer les classes que l’on souhaite exposer à d’autres Bundles, ceci s’effectue en exportant les packages des classes que l’on souhaite rendre accéssibles.

Export Package

Ici nous allons rendre accéssible les classes du package org.akrogen.gestcv.domain du Bundle org.akrogen.gestcv.domain en exportant le package org.akrogen.gestcv.domain. Cette information sera contenu dans le fichier MANIFEST.MF (balise Export-Package).

Nous allons modifier le MANIFEST.MF du Bundle org.akrogen.gestcv.domain via l’onglet Runtime de l’editor PDE:

Cliquez sur le bouton Add… qui ouvre la boite de dialogue qui propose tous les packages du Bundle.

Sélectionnez le package org.akrogen.gestcv.domain, puis cliquez sur OK. Le liste Export packaged doit être renseigné avec le package org.akrogen.gestcv.domain. Sauvegardez et l’interface UserService doit compiler à nouveau :

Vous pouvez vérifiez que cette action d’export package a mis à jour le fichier MANIFEST.MF avec ce contenu :

Export-Package: org.akrogen.gestcv.domain

Protection des Activator

Maintenant que nous avons exportés le package org.akrogen.gestcv.domain dans le Bundle org.akrogen.gestcv.domain, n’importe quel Bundle peut accéder aux classes du package org.akrogen.gestcv.domain qui à ce stade sont :

• la classe org.akrogen.gestcv.domain.User qui est le domaine Utilisateur.
• la classe org.akrogen.gestcv.domain.Activator qui est le BundleActivator qui affiche une trace dans la console OSGi lorsque le bundle est démarré et stoppé.

Le Bundle Activator ne doit pas être accéssible via un autre Bundle. Cette classe doit juste être accéssible par le conteneur OSGi. Hors à ce stade, il est possible d’accéder à la classe org.akrogen.gestcv.domain.Activator, dans des classes d’un autre Bundle. Pour vous rendre compte de ce problème, tappez Activator dans la classe UserService et vous pourrez constater qu’il est possible d’accéder à org.akrogen.gestcv.domain.Activator :

Pour régler, ce problème il faut mettre cette classe Activator dans un package protégé. Les plugins d’Eclipse utilise souvent le package internal pour mettre les classes que le Bundle ne doit pas exposer. Nous allons procéder de la même manière et mettre la classe Activator dans le package org.akrogen.gestcv.domain.internal.

Refactor ->Move

Ici nous allons effectuer un refactoring pour mettre la classe org.akrogen.gestcv.domain.Activator dans le package org.akrogen.gestcv.domain.internal. Le fait de passer par un refactoring Eclipse, permettra de mettre à jour aussi le fichier MANIFEST.MF (Bundle-Activator).

Sélectionnez la classe org.akrogen.gestcv.domain.Activator, puis cliquez sur le bouton droit de la souris pour accéder au menu contextuel. Accédez à l’item Refactor->Move… :

La fenêtre de dialogue Move s’ouvre :

Cliquez sur le bouton Create Package…, la fenêtre de création de packages s’ouvre :

Saisissez dans le champs Name, la valeur org.akrogen.gestcv.domain.internal, puis cliquez sur OK, puis sur le bouton Finish . Le refactoring de changement de package s’est effectué et le MANIFEST.MF a été modifie aussi avec la valeur suivante :

Bundle-Activator: org.akrogen.gestcv.domain.internal.Activator

Sources de org.akrogen.gestcv.services

MANIFEST.MF / Export-Package

Exporter le package org.akrogen.gestcv.services du Bundle org.akrogen.gestcv.services pour exposer uniquement aux autres Bundles l’interface UserService et la factory ServicesFactory. Le fichier MANIFEST.MF du bundle org.akrogen.gestcv.services doit avoir ce contenu ajouté :

Export-Package: org.akrogen.gestcv.services

Activator

Modifiez le package de la classe Activator du Bundle org.akrogen.gestcv.services dans le package org.akrogen.gestcv.services.internal. Le fichier MANIFEST.MF du bundle org.akrogen.gestcv.services doit avoir ce contenu ajouté :

Bundle-Activator: org.akrogen.gestcv.services.internal.Activator

Modifiez le code de cette classe comme suit pour tracer le démarrage/stoppage du Bundle :

UserServiceImpl

Créez la classe org.akrogen.gestcv.services.impl.UserServiceImpl comme suit :

ServicesFactory

Créez la classe org.akrogen.gestcv.services.ServicesFactory comme suit :

org.akrogen.gestcv.simpleosgiclient

Ici nous allons transformer le projet Java classique org.akrogen.gestcv.simplemainclient en Bundle OSGi. Les sources Java de notre Bundle seront identiques à celui du projet Java classique. Créez le Bundle org.akrogen.gestcv.simpleosgiclient avec les paramètre suivants :

avec les paramètres suivants :

• champs ID: org.akrogen.gestcv.simpleosgiclient
• champs Version: 1.0.0.qualifier.
• champs Name: GestCV Simple OSGi Client
• champs Provider: Akrogen
• champs Execution Environment: J2SE-1.5.
• option generate an activator, a Java class that controls the plug-in’s life cycle cochée .
• Activator : org.akrogen.gestcv.simpleosgiclient.internal.Activator

Ajoutez les dépendances (avec Require-Bundle) aux Bundles org.akrogen.gestcv.domain et org.akrogen.gestcv.services.

Modifiez le code de la classe org.akrogen.gestcv.simpleosgiclient.internal.Activator comme suit pour tracer le démarrage/stoppage du Bundle :

Avant de relancer, vérifier que les 3 bundles OSGi sont cochés dans la configuration GestCV OSGi :

Relancez (via GestCV OSGi ) Equinox et la console OSGi doit afficher ceci :

Les Traces de type « Start Bundle…. » montre que la méthode start de chaque BundleActivator a été appelé.

Problème résolu par OSGi

UserServiceImpl protégé

Dans la classe Activator du Bundle org.akrogen.gestcv.simpleosgiclient, si vous tappez User, la complétion ne propose plus la classe UserServiceImpl, car cette classe n’est pas dans un package qui est exporté par le Bundle :

Bundle OSGi/ClassLoader

Ici nous allons effectuer les mêmes tests que ceux effectués dans le billet [step1] avec des projets Java classiques (dépendances classiques Java Build Path). Nous allons dans un premier temps montrer que chaque Bundle OSGi a son propre ClassLoader. Pour s’en rendre compte nous allons afficher le ClassLoader dans la console Eclipse.

Modifiez les 3 classes Activator en modifiant la méthode start comme suit :

Relancez (via GestCV OSGi ) Equinox et vous verrez dans la console OSGi :

qui montre que chaque Bundle OSGi a son propre ClassLoader.

Avec les dépendances classiques Java Build Path, nous avons vu qu’il y avait un ClassLoader unique et nous avons mis en évidence ce problème avec l’utilisation de versions différentes de la librairie Apache commons-lang*.jar. Nous allons effectuer la même chose avec nos Bundle OSGi :

Ce schéma montre que :

• le Bundle Client org.akrogen.gestcv.simpleosgiclient pointera sur la librairie commons-lang-1.0.jar de version 1.0. Cette librairie est stockée dans le repertoire lib (qu’il faut créer) du Bundle.
• le Bundle Services org.akrogen.gestcv.services pointera sur la librairie commons-lang-2.4.jar de version 2.4. Cette librairie est stockée dans le repertoire lib (qu’il faut créer) du Bundle.

Vous pouvez télécharger le zip org.akrogen.gestcv_step3-commons-lang.zip qui contient les Bundles avec les librairies commans-lang*.jar.

Pour rappel, la différence entre ces 2 versions de commans-lang*.jar est que la classe utilitaire org.apache.commons.lang.StringUtils possède une méthode StringUtils#isBlank(String String) dans la version 2.4 et pas dans la version 1.0. Nous souhaitons utiliser StringUtils#isBlank(String String) dans la couche Services.

Runtime/Add Jar (commons-lang-2.4.jar)

Ici nous allons ajouter au Bundle org.akrogen.gestcv.services la librairie jar commons-lang-2.4.jar. Cette dépendance se retrouvera au final dans le MANIFEST.MF du Bundle (Bundle-ClassPath). Ouvrez le fichier MANIFEST.MF du Bundle et cliquez sur l’onglet Runtime :

Cliquez sur le bouton Add…, la fenêtre de sélection de JAR s’ouvre :

Sélectionnez le JAR lib/commons-lang-2.4.jar, puis cliquez sur OK, la librairie est ajoutée :

Sauvegardez et vous pourrez voir que le MANIFEST.MF a été modifié en ajoutant ce contenu :

Utilisation commons dans la couche Services

Modifiez la méthode start de la classe org.akrogen.gestcv.services.internal.Activator, BundleActivator de la couche Services pour utiliser la méthode utilitaire StringUtils#isBlank(String str) de commons-lang-2.4.jar :

Runtime/Add Jar (commons-lang-1.0.jar)

Ajoutez la librairie commons-lang-1.0.jar dans le Bundle org.akrogen.gestcv.simplemainclient

Utilisation commons dans la couche Cliente

Modifiez la méthode start de la classe org.akrogen.gestcv.simpleosgiclient.internal.Activator, BundleActivator de la couche Cliente pour utiliser la méthode utilitaire StringUtils#isEmpty(String str) de commons-lang-1.0.jar :

Relancez (via GestCV OSGi ) Equinox, la console OSGi affiche ceci :

ce qui montre qu’il est possible d’avoir une version d’une librairie par Bundle sans avoir de conflit.

Conclusion

A cette étape nous avons vu que les Bundle OSGi gérent leur dépendances (avec d’autres Bundles, avec des JAR internes au Bundle) via le fichier MANIFEST.MF avec Require-Bundle ou Import-Package. Un Bundle expose ses classes qu’il souhaite rendre visible aux autres Bundles via Export-Package qui est aussi une information contenu dans le MANIFEST.MF. Un Bundle a son propre ClassLoader. Les Bundles sont gérés par un conteneur OSGi (Equinox) qui fournit une console OSGi qui permet d’arrêter/stopper à chaud des Bundles.

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.

Mes premiers pas avec OSGi

A mes débuts en OSGi j’ai du lire beaucoup d’articles et de documentations pour me rendre compte de la puissance d’OSGi. J’aimerais mettre en évidence tout ce que j’adore dans OSGi à travers d’exemples concrets que j’améliorerais au fur et à mesure pour comprendre par la suite le mécanisme de Spring DM. Ma démarche est d’expliquer OSGi par le code généré par PDE et ensuite expliquer les concepts d’OSGi et pas l’inverse comme dans la plupart du temps. Si vous ne connaissez pas OSGI, je vous conseille de lire l’excellent article Programmation par composant avec la technologie OSGi (1ère partie). Il est en français et donne une bonne vision de l’architecture de OSGI et de son jargon (Bundle…).

Lorsque j’ai démarré avec OSGi, la difficulté que j’ai eu a été d’avoir une vision d’ensemble de son architecture et de son Jargon (Bundle OSGi, Equinox, Target Platform….). Je vais faire une comparaison (très très simpliste) avec une architecture JEE basée sur un serveur (Tomcat, Jetty…) pour s’imprégner des notions d’OSGi. Mais attention, je ne dis pas que OSGi est équivalent à JEE!!! Loin de là.

Architecture JEE

Dans une architecture JEE basée sur un serveur, ce dernier joue le rôle de conteneur qui hébérge des applications WEB et qui orchestre le cycle de vie des application WEB (appel des Filtres JEE, des Servlets d’une application WEB ). Un serveur contient des librairies JAR sur lesquelles s’appuient les application WEB. Par exemple Tomcat contient la librairie servlet-api.jar dans son répertoire common/lib qui est l’API standard JEE qui fournit les interfaces javax.servlet.Filter, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletSession.

Il existe plusieurs implémentations de serveurs, comme Tomcat, Jetty, etc. qui implémentent en interne ces interfaces et les applications WEB n’utilisent que ces interfaces ce qui permet de déployer une application WEB (en théorie si l’application WEB n’utilise pas des fonctionnalités spécifiques au serveur) sur différents serveurs.

Architecture OSGi

Dans une architecture OSGi, il y a aussi un conteneur qui hébérge des Bundles OSGi et qui orchestre leur cycle de vie. Un conteneur OSGi contient uniquement (du moins dans Equinox) une libraire JAR qui est l’API d’OSGi. Cette librairie est un Bundles OSGi sur lesquels s’appuient tous les autres Bundles OSGi. Il est par contre possible de choisir les librairies JAR (Bundle) à ajouter au conteneur en définissant le Target Platform. Eclipse fournit la librairie org.eclipse.osgi_3.5.0.v20090520.jar dans son répertoire plugins qui contient l’API standard OSGi qui fournit les interfaces OSGi org.osgi.framework.BundleActivator, org.osgi.framework.BundleContext et que nous allons utiliser dans notre Bundle. Ce JAR contient aussi l’implémentation (Equinox) de l’API OSGi.

2 types de Bundles peuvent donc être lancés via le conteneur OSGi :

• les Bundles du workspace Eclipse qui sont les Bundles en cours de développement.
• les Bundles définis dans la Target Platform qui par défaut sont les tous ceux contenus dans le répertoire plugins d’Eclipse.

Il existe plusieurs implémentations de conteneurs OSGi comme Equinox, Felix, qui implémentent en interne ces interfaces et les Bundles OSGi n’utilisent que ces interfaces ce qui permet de déployer un Bundle OSGi (en théorie s’il n’utilise pas des fonctionnalités spécifiques au conteneur) sur différents conteneurs OSGi. Les Plug-ins Eclipse sont des Bundles OSGi qui sont orchestrés par Equinox. C’est ce conteneur OSGi que nous utiliserons et qui est proposé par défaut.

Récapitulatif

Voici un tableau récapitulatif (très simpliste) qui compare les notions de Serveur JEE et conteneur OSGi :

Création de notre 1er Bundle

PDE (Plug-in Development Environment) est un ensemble de plugins Eclipse qui fournit des outils pour créer, développer, tester des plugins Eclipse, des applications RCP et des Bundle OSGi. Un Plug-in Eclipse est en fait un Bundle OSGi. Dans cette section nous allons nous occuper de transformer notre projet Java org.akrogen.gestcv.domain en Bundle OSGi (projet Plug-in). Il est possible d’effectuer cette tâche en sélectionnant le projet Java, bouton droit pour ouvrir le menu contextuel, puis sélectionnez le menu Configure/Convert to Plug-in Projects… mais cette méthode demande quand même des manipulations à effectuer ensuite (notemment pour gérer les dépendances via OSGi). Je préfère donc recommencer depuis le début et passer par les wizards (PDE) de création de Bundle OSGi.

Création Bundle

Ici nous allons créer le Bundle (projet Plug-in) org.akrogen.gestcv.domain. Pour cela sélectionnez le menu File/New/Other puis Plug-in Development/Plug-in Project :

Cliquez sur le bouton Next, puis :

• renseignez le champs Project name par org.akrogen.gestcv.domain.
• sélectionnez le bouton radio an OSGI framework car nous souhaitons développer un Bundle OSGi et pas un Plug-in Eclipse, puis la combo standard car notre Bundle n’a pas besoin de fonctionnalités spécifiques à Equinox (conteneur OSGi aussi utilisé pour les Plug-in Eclipses). Il pourra ainsi fonctionner sur n’importe quel conteneur OSGI.

Cliquez sur le bouton Next, le wizard qui permet de configurer le Bundle s’ouvre en pré-remplissant la plupart des champs. Voici une copie d’écran de ce wizard où j’ai mis en rouge ce que j’ai modifié :

• le champs ID est l’identifiant de notre Bundle. Il est pré-rempli en utilisant le nom du projet.
• le champs Version est la version de notre Bundle. Il est pré-remplit avec 1.0.0.qualifier.
• le champs Name est le nom de notre Bundle. Cette information n’est pas très importante. Dans ce billet je l’ai renseigné avec GestCV Domain
• le champs Provider est généralement le nom de la société qui créé le Bundle. Cette information n’est pas très importante. Dans ce billet je l’ai renseigné avec Akrogen
• le champs Execution Environment indique la version minimale de la JRE pour que le Bundle puisse être éxécuté.
• l’option generate an activator, a Java class that controls the plug-in’s life cycle est cochée par défaut. Nous la laissons cochée pour générer une classe Activator dans ce Bundle, même si au final nous n’en n’aurrons pas vraiment besoin pour ce Bundle .

Cliquez sur le bouton Finish pour générer le projet Bundle OSGi.

Contenu Bundle créé

Voici le contenu du projet Bundle OSGi générée par PDE :

MANIFEST.MF

Un projet Bundle OSGi (projet Plug-in) est un projet Java classique. PDE à généré le fichier classique de méta données META-INF/MANIFEST.MF mais avec des informations de type Bundle* (Bundle-name…). Ces informations sont les méta donnés du Bundle OSGi (provenant du wizard de création du Bundle). Elle permettent d’indiquer l’identifiant du Bundle (Bundle-SymbolicName), sa version (Bundle-Version) la JRE minimale dans laquelle le Bundle peut être exécuté (Bundle-RequiredExecutionEnvironment). Toutes ces méta donnés sont ensuite utilisées par le conteneur OSGi pour par exemple tester si le Bundle peut être lancé en testant la version de la JRE.

BundleActivator

PDE à généré la classe org.akrogen.gestcv.domain.Activator (dù à l’option generate an activator, a Java class that controls the plug-in’s life cycle coché dans le wizard PDE). Voici le code généré de cette classe :

Cette classe implémente l’interface OSGi org.osgi.framework.BundleActivator qui permet de personaliser le lancement (start) et l’arrêt du bundle (stop). En effet un Bundle OSGi suit un cycle de vie orchestré toujours par le conteneur d’OSGi. Pour plus d’information sur ce sujet je vous conseille de lire la section 3.2. Cycle de vie des bundles.

Pour indiquer au conteneur OSGi que l’on souhaite personnaliser le lancement/arrêt du Bundle via le BundleActivator org.akrogen.gestcv.domain.Activator, ceci s’effectue via la méta donnée Bundle-Activator du fichier MANIFEST.MF comme ceci :

Bundle-Activator: org.akrogen.gestcv.domain.Activator

La classe org.akrogen.gestcv.domain.Activator implémente l’interface OSGi org.osgi.framework.BundleActivator. Notre Bundle doit donc faire référence à un jar qui contient cette interface. Eclipse Galileo fournit le JAR /plugins/org.eclipse.osgi_3.5.0.v20090520.jar qui contient les interfaces OSGi. Ce JAR est contenu dans le répertoire plugins de Eclipse. C’est en fait un Bundle OSGi dont on peut faire dépendre n’importe quel Bundle (pour l’utiliser nous devons le mettre dans la Target Platform). Le JAR /plugins/org.eclipse.osgi_3.5.0.v20090520.jar qui est un Bundle à aussi un MANIFEST.MF comme ceci :

La méta-donnée Export-Package permet d’indiquer quels sont les packages (et version) qui sont exportés,

autrement dit seules les classes qui sont incluses dans les packages exportés (e : org.osgi.framework) sont accéssibles via d’autres Bundles.

Dépendances entre Bundle

Il existe deux manières d’utiliser les classes (exportès) d’un autre Bundle :

• Require-Bundle : ce type de dépendance permet de dépendre explicitement sur un Bundle identifié par son ID. Les classes de tous les packages exportés par le Bundle dont on souhaite dépendre sont accéssibles. Voici ce que donnerait ce type de dépendance :
  Require-Bundle: org.eclipse.osgi
• Import-Package : ce type de dépendance indique juste que l’on souhaite importer un package particlier. Ici nous ne connaissons pas le Bundle qui expose ces packages. C’est ce type de dépendance qui a été utilisé par PDE :
  Import-Package: org.osgi.framework. Ce package provient du Bundle d’ID org.eclipse.osgi

Import-Package

La gestion de dépendances de notre Bundle org.akrogen.gestcv.domain au Bundle org.eclipse.osgi s’effectue via le MANIFEST.MF de la manière suivante :

Import-Package: org.osgi.framework;version="1.3.0"

Ceci signifie que l’on souhaite utiliser les classes qui sont dans le package org.osgi.framework de version au minimum 1.3.0.

Ce type de dépendance ne lie pas directement notre Bundle org.akrogen.gestcv.domain au Bundle org.eclipse.osgi. L’avantage de cette technique est que si Eclipse effectue un refactoring en mettant les classes du package org.osgi.framework dans un autre Bundle que org.eclipse.osgi, notre Bundle continuera de fonctionner. Ceci signifie que l’on souhaite utiliser les classes qui sont dans le package org.osgi.framework de version au minimum 1.3.

Require-Bundle

PDE a généré Import-Package: org.osgi.framework;version="1.3.0" pour pouvoir utiliser les classes du package org.osgi.framework dans notre Bundle. Mais Il aurait été aussi possible d’utiliser Require-BundleRequire-Bundle: org.eclipse.osgi

Configuration de notre 1er Bundle (PDE Editor)

Si vous souhaitez lancer directement le Bundle, vous pouvez vous affranchir de lire cette section. PDE founit l’Editor PDE qui s’ouvre en éditant le fichier MANIFEST.MF. Il permet de gérer (dans notre cas de Bundle) le fichier MANIFEST.MF à travers plusieurs onglets.
Si vous avez acceptez d’ouvrir la perspective PDE ou si vous double cliquez sur le fichier MANIFEST.MF, l’editor PDE s’ouvre. Il est composé de plusieurs onglets :

• Onglet Overview: donne une vue d’ensemble du Bundle OSGi sur les méta-données autre que les dépendances.
• Onglet Dependencies: pemet de gérer les dépendances de type Require-Bundle. et Import-Package.
• Onglet Runtime: pemet de gérer les packages exportés Export-Package (nous y reviendrons dans le prochain billet).
• Onglet MANIFEST.MF: affiche le contenu du fichier MANIFEST.MF géré dans l’editor.
• Onglet build.properties: j’y reviendrais lorsque nous en aurrons besoin.

Onglet Overview

Cet onglet donne une vue d’ensemble du Bundle OSGi sur les méta-données autre que les dépendances :

On retrouve les informations du Bundle comme l’ID (Bundle-SymbolicName), l’Activator (Bundle-Activator), la JRE (Bundle-RequiredExecutionEnvironment),… Les liens Launch the framework et Launch the framework in Debug mode permettent de lancer Equinox et par conséquent lancer tous les Bundles du Workspace et ceux définis dans la Target Platform.

Onglet Dependencies

Cet onglet pemet de gérer les dépendances de type Require-Bundle. et Import-Package.

Add Require-Bundle

Ici nous allons dépendre explicitement du Bundle OSGi org.eclipse.osgi au lieu du package. Avant d’effectuer cette action, supprimez la dépendance Import-Package sur org.osgi.framework. Pour cela, allez dans l’onglet Runtime, sélectionnez org.osgi.framework dans la liste Import Packages puis cliquez sur le bouton Remove.

Cliquez sur le bouton Add… à coté de la liste Required Plug-in, ceci ouvre la fenêtre de dialogue qui propose tous les Bundles disponibles (ceux du Workspace et ceux de la Target Platform. Recherchez le Bundle org.eclipse.osgi :

Cliquez sur OK, le Bundle est ajouté :

Sauvegardez ensuite pour enregistrer le MANIFEST.MF. Le Bundle org.akrogen.gestcv.domain doit toujours compiler.

Add Import-Package

Ici nous allons utiliser (à nouveau) le package org.osgi.framework au lieu du Bundle org.eclipse.osgi. Avant d’effectuer cette action, supprimez la dépendance Require-Bundle sur org.eclipse.osgi. Pour cela, allez dans l’onglet Dependencies, sélectionnez org.eclipse.osgi dans la liste Required Plug-in puis cliquez sur le bouton Remove. Cliquez sur le bouton Add… à coté de la liste Imported Packages, ceci ouvre la fenêtre de dialogue qui propose tous les packages disponibles (packages exportès par l’ensemble des Bundle du Workspace et de la Target Platform. Recherchez le package org.osgi.framework :

Cliquez sur OK, le package est ajouté :

Sauvegardez ensuite pour enregistrer le MANIFEST.MF. Ici nous avons une dépendance sur la version 1.5.0 mais nous la changeons en version 1.3.0 (via l’onglet MANIFEST.MF) car cette version nous suffit (c’est celle d’ailleurs générée par PDE).

Onglet Runtime

L’onglet Runtime permet de sélectionner les packages à exporter et définir si besoin des dépendances à des (JAR) qui serait stockés dans le Bundle :

Onglet MANIFEST.MF

Cet onglet affiche le contenu du fichier MANIFEST.MF géré dans l’editor :

Lancement de notre 1er Bundle

A cette étape nous souhaitons lancer notre Bundle org.akrogen.gestcv.domain (qui ne fait rien pour l’instant). Le lancement d’un Bundle consiste à démarer le conteneur OSGi (Equinox) en lui indiquant les Bundles qu’il doit executer. Pour créér cette configuration, ouvrez le fichier MANIFEST.MF, puis cliquez sur le lien Launch the framework in Debug mode de l’onglet Overview.

Cette action lance Equinox avec les Bundles du workspace et ceux définis dans la Target Platform définit par défaut. Dans mon cas je suis dans un environnement Java5 et j’ai l’erreur suivante dans la console :

Cette erreur est intéressante car elle montre que le conteneur OSGi a lancé un Bundle (lequel?) qui a définit dans son MANIFEST.MF son Bundle-RequiredExecutionEnvironment avec JavaSE-1.6. Ce Bundle vient de la Target Platform par défaut qui va en fait executer tous les Bundles (Plug-in généralement) de Eclipse (répertoire plugins). Dans notre cas nous n’avons pas besoin de tous ces plugins pour éxécuter notre Bundle et c’est pour cela que nous personnaliserons notre Target Platform. Mais nous pouvons quand même continuer nos tests.

Dans la console OSGi, saisissez la commande ss (Short Status):

Cette commande permet d’afficher la liste des Bundles qui ont été résolus, activés, non résolus. Vous pourrez constater que notre Bundle OSGi org.akrogen.gestcv.domain a le status ACTIVE, ce qui signifie que tout s’est bien passé.

Run

A cette étape nous pouvons lancer notre Bundle. Si vous ne souhaitez pas paramétrer la Target Platform, importer le launch OSGi GestCV.launch. Mais si vous ne connaissez pas la notion de Target Platform, je vous conseille de lire ce qui suit.

Le clic sur le lien Launch the framework in Debug mode de l’onglet Overview a en fait généré une Configuration de nom OSGI Framework. Pour éditer cette configuration, cliquez sur l’icône du menu globale Run, puis Run Configurations….

La fenêtre de dialogue Run Configurations s’ouvre et montre la configuration de lancement d’Equinox. On peut voir que les Bundles lancés sont ceux du workspace et ceux de la Target Platform (qui sont en fait tous les plugins de Eclipse).

Profitez pour renommez le nom de la Configuration OSGI Framework en OSGI GestCV.

Target Platform

Comme nous l’avons vu précedemment la Target Platform par défaut ne nous convient pas car elle contient tous les Bundles de Eclipse. Nous allons définir notre propre Target Platform qui sera ausi ensuite utillisée par notre Application RCP. Pour personnaliser notre Target Platform, accédez au menu Window/Preferences qui ouvre la fenêtre de Preferences puis accédez dans le Treeview au noeud Plug-in Development/Target Platform. La Target Platform par défaut est sélectionnée :

Cliquez sur le bouton Add, puis sélectionnez Template puis Base RCP (Binary Only), qui est un template qui permet de définir notre Target Platform qu’avec les Bundles OSGi nécéssaires pour une application RCP :

Cliquez sur le bouton Next :

Nommez la Target Platform GestCV Target Platform. L’onglet locations indique qu’il y a 31 Bundles qui sont concernés. Si vous cliquez sur l’onglet Content, vous pourrez visualiser les 31 Bundles concernés :

Cliquez sur le bouton Finish :

Cliquez sur le bouton OK le workspace se recompile. Relancez le Bundle, la console ne doit plus afficher d’erreurs (car le Bundle JavaSE-1.6 n’est plus dans la Target Platform) et le nombre de Bundle lancé a considérablement diminué :

Si vous revenez dans Run Configuration, vous pourrez constater que la plupart des Bundles (Plug-In) de Eclipse sont décochés :

Console OSGi

Comme nous avons pu le voir, le conteneur OSGi peut être interrogé via des commandes (ex : ss) dans la console Eclipse. L’article Explore Eclipse’s OSGi console liste toutes les commandes disponibles.

Nous allons modifier la classe org.akrogen.gestcv.domain.Activator pour tracer le démmarage (start) et l’arrêt (stop) de notre Bundle org.akrogen.gestcv.domain. Pour cela modifier le code de cette classe comme suit :

Relancez le Bundle OSGi via la configuration OSGi GestCV,la console OSGi affiche ceci :

osgi> Start Bundle [org.akrogen.gestcv.domain]

Notre méthode org.akrogen.gestcv.domain.Activator#start() a été appelée. En effectuant ss, dans la console, un ID technique est associé à chaque Bundle. Dans mon cas j’ai :

Notre Bundle org.akrogen.gestcv.domain à un ID égale à 7 et le Bundle org.eclipse.osgi sur lequel on dépend a un ID égale à 0.

Saisissez dans la console stop 7

La consle OSGi affiche :

Notre méthode org.akrogen.gestcv.domain.Activator#stop() a été appelée.

Saisissez dans la console start 7

La consle OSGi affiche :

Ceci montre qu’il est possible d’arrêter/stopper des Bundles OSGi à chaud sans devoir redémarrer le conteneur OSGi. Si vous stoppez le Bundle org.eclipse.osgi via la commande stop 0, la console affiche :

L’arrêt du Bundle org.eclipse.osgi arrête aussi notre Bundle org.akrogen.gestcv.domain car il est lié à ce premier.

Saisissez dans la console start 0, la console affiche une erreur :

J’explique cette erreur par le fait que nous avons arrêter le bundle primordial OSGi (qui définit l’API OSGi).

OSGi GestCV.launch

Import Launch

Dans le zip org.akrogen.gestcv_step2.zip vous trouverez un fichier OSGi GestCV.launch qui est un export du launch OSGi GestCV qui a été créé dans ce billet. Pour importer ce launch, accéder au menu File/Import puis sélectionnez le noeud Run/Debug->Launch Configurations

Cliquez sur le bouton Next puis sélectionnez le fichier launch OSGi GestCV.launch du zip :

Cliquez sur le bouton Finish pour importer le launch. Cet import a créé le launch OSGi GestCV qui permet entre autres de sélectionner que les bundles dont on a besoin dans la Target Platform. Pour l’utiliser, cliquez sur l’icône du menu globale Run, puis Run Configurations…. Le launch OSGi GestCV doit apparaître, avec tous les Bundles du workspace et ceux de la Target Platform personnalisée, sélectionnez le et cliquez sur le bouton Run.

Export Launch

L’export d’un launch de type OSGi Framework permet dans un projet de partager sa Target Platform avec d’autres développeurs. Pour effectuer un export de launch de type OSGi Framework, accéder au menu File/Export puis sélectionnez le noeud Run/Debug->Launch Configurations :

Cliquez sur le launch OSGi GestCV puis sur le bouton Finish pour exporter ce launch dans un fichier OSGi GestCV.launch :

Conclusion

Dans ce billet nous avons créé notre premier Bundle OSGi et configuré la Target Platform. Nous avons vu que le conteneur OSGi fournissait uen console OSGi qui permet de d’administrer les Bundles (arrêt, lancement des Bundles). Dans le prochain billet nous allons transformer les 2 autres projets Jave Services et Client en Bundle OSGi, ce qui nous permettra de mettre beaucoup plus en valeur OSGi.

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.

Prérequis

Pour la rédaction de mes billets, j’ai téléchargé la dernière version d’Eclipse qui actuellement est Eclipse Galileo (Eclipse 3.5). Je conseille plus exactement de télécharger la distribution Eclipse for RCP/Plug-in Developers (183 MB ). Cette distribution est faite pour développer des applications RCP, les sources de l’API RCP y sont disponibles. Cependant je pense que dans un billet je vais devoir utiliser une application WEB classique. Un serveur (Tomcat) sera nécéssaire et j’utiliserais sûrement la distribution Eclipse IDE for Java EE Developers (189 MB ). Dans la suite des billets nous aurrons aussi besoin d’une Base de Données (mais j’y reviendrais).

org.akrogen.gestcv.domain

Le projet org.akrogen.gestcv.domain est le domaine applicatif du projet, il contiendra tous les POJO de notre projet.

Création Java Project

Ici nous allons créer le projet Java org.akrogen.gestcv.domain pour cela sélectionnez le menu File/New/Other puis Java Project :

Cliquez sur Next et renseignez le champs Project name avec org.akrogen.gestcv.domain :

Cliquez sur Finish le projet Java est créé.

Classe User

Créez la classe org.akrogen.gestcv.domain.User comme suit :

org.akrogen.gestcv.services

Nous allons créer le projet Java org.akrogen.gestcv.services qui sera notre couche service qui contiendra le service UserService qui retournera la liste des User. Pour cela, créez le projet Java org.akrogen.gestcv.services. Ce projet doit faire référence au projet Java org.akrogen.gestcv.domain car il doit retourner une liste de POJO User.

Java Build Path/Add Project

Ici nous allons ajouter au projet org.akrogen.gestcv.services une dépendance sur le projet org.akrogen.gestcv.domain. Pour cela sélectionnez le projet org.akrogen.gestcv.services
puis cliquez sur le bouton droit. Sélectionnez l’item Properties puis le noeud Java Build Path et sélectionnez l’onglet Projects :

Cliquez sur le bouton Add. Ceci ouvre uen boîte de dialogue qui propose tous les projets du workspace dont on peut dépendre :

Sélectionnez le projet org.akrogen.gestcv.domain, puis cliquez sur OK. La dépendance est maintenant créée :

Interface UserService

Créez l’interface org.akrogen.gestcv.services.UserService comme suit :

Implémentation UserServiceImpl

Créez la classe org.akrogen.gestcv.services.impl.UserServiceImpl comme suit :

On peut remarquer que les implémentations des services se retrouvent dans le packages *.impl. Ceci est une bonne règle de nommage qui permet de distinguer facilement les interfaces aux implémentations. Nous verrons dans le prochain billet que cette règle de nommage nous servira aussi pour rendre inaccéssible cette classe aux autres Bundles (projet Java) dans un environnement OSGI.

Factory de Services

Créez la factory de services org.akrogen.gestcv.services.ServicesFactory comme suit :

La factory de services est un singleton qui a une méthode ServicesFactory#getUserService() qui retourne une implémentation de l’interface UserService.

org.akrogen.gestcv.simplemainclient

Créez le projet Java org.akrogen.gestcv.simplemainclient. Ajoutez les dépendances aux 2 projets org.akrogen.gestcv.domain et org.akrogen.gestcv.services .

Créez la classe org.akrogen.gestcv.simplemainclient.SimpleMainClient comme suit :

Ce Main Java utilise la méthode UserService#findAllUsers() pour afficher la liste de User. A cette étape on peut lancer le client qui appelle le service qui retourne la liste d’utilisateurs.

Run As – Java Application

Pour lancer le main de la classe SimpleMainClient, sélectionnez la classe, puis ouvrez le menu contextuel (en cliquant sur le bouton droit) et cliquez sur Run As / Java Application :

La console eclipse doit afficher la liste des utilisateurs :

Problème Java Build Path

Les dépendances entre les projets est effectuées via le Java Build Path classique qui lorsque l’on lance le Main de SimpleMainClient construit le classpath avec ces projets. Nous allons voir les 2 problèmes avec ce type de dépendance.

UserServiceImpl Non protégé

Dans la classe org.akrogen.gestcv.simplemainclient.SimpleMainClient, si vous tentez d’utiliser la classe UserServiceImpl, vous pourrez constater que l’autocomplétion propose cette classe :

Cette classe ne devrait jamais être utilisée par une classe autre que celle de la factory de Service. A ce stade la classe SimpleMainClient peut utiliser UserServiceImpl. Ceci est dangereux surtout si la version suivante du projet
org.akrogen.gestcv.services effectue un refactoring en renommant UserServiceImpl ou en changeant ces méthodes.

En pur Java il est impossible de régler ce problème si ce n’est de déclarer la classe UserServiceImpl en private et de la mettre dans le même package que la classe ServicesFactory. Mais cette solution ne permet plus de mettre les classes dans des packages souhaités ce qui nous ramenerait à avoir un seul niveau de package pour toutes les interfaces et implémentations.

ClassLoader unique

Un ClassLoader permet comme son nom l’indique de charger des classes . Dans notre cas les 3 projets partagent le même ClassLoader. Pour s’en rendre compte nous allons afficher le ClassLoader dans la console Eclipse.

Modifiez la classe SimpleMainClient comme suit :

et modifiez la classe ServicesFactory comme suit :

Relancez et vous verrez dans la console :

qui montre que les 2 classes partagent le même ClassLoader.

Ceci est problématique car chaque projet ne peut pas avoir sa propre version de jar d’une librairie donnée. Nous allons illustrer le problème en utilisant 2 versions différentes de la librairie Apache commons-lang*.jar dans 2 projets :

Ce schéma montre que :

• le projet Java Client org.akrogen.gestcv.simplemainclient pointera sur la librairie commons-lang-1.0.jar de version 1.0. Cette librairie est stockée dans le repertoire lib (qu’il faut créer) du projet.
• le projet Java Services org.akrogen.gestcv.services pointera sur la librairie commons-lang-2.4.jar de version 2.4. Cette librairie est stockée dans le repertoire lib (qu’il faut créer) du projet.

Vous pouvez télécharger le zip org.akrogen.gestcv_step1-commons-lang.zip qui contient les projets avec les librairies commans-lang*.jar.

La différence entre ces 2 versions de commans-lang*.jar est que la classe utilitaire org.apache.commons.lang.StringUtils possède une méthode StringUtils#isBlank(String String) dans la version 2.4 et pas dans la version 1.0. Nous souhaitons utiliser StringUtils#isBlank(String String) dans la couche Services.

Java Build Path/Add Jar (commons-lang-2.4.jar)

Ici nous allons ajouter au projet org.akrogen.gestcv.services la librairie jar commons-lang-2.4.jar. Pour cela sélectionnez le projet org.akrogen.gestcv.services puis cliquez sur le bouton droit. Sélectionnez l’item Properties puis le noeud Java Build Path puis sélectionnez l’onglet Libraries :

Cliquez sur le bouton Add JARs…

Puis cliquez sur OK, la librairie est ajoutée :

Utilisation commons dans la couche Services

Modifiez le code de ServicesFactory pour utiliser la méthode utilitaire StringUtils#isBlank(String str) de commons-lang-2.4.jar :

Java Build Path/Add Jar (commons-lang-1.0.jar)

Ajoutez la librairie commons-lang-1.0.jar dans le projet org.akrogen.gestcv.simplemainclient

Puis changez l’ordre de chargement des librairies pour que la librairie commons-lang-1.0.jar soit chargé AVANT le projet org.akrogen.gestcv.services (Services), autrement dit avant le chargement de la libraire commons-lang-2.4.jar :

Relancez le Main SimpleMainClient et vous aurrez l’erreur suivante :

La méthode StringUtils.isBlank(String str) n’est pas trouvée car la librairie commons-lang-1.0.jar est chargée AVANT la librairie commons-lang-2.4.jar. Il est donc impossible de faire cohabiter 2 versions différentes avec des dépendances classiques. Ce problème se trouve aussi dans les applications WEB lorsque l’application WEB a une version d’un JAR et que le serveur (Tomcat…) a une autre version du même JAR.

Conclusion

Dans ce billet nous avons mis en place un client java qui appelle un service. Nous avons vu les 2 problemes posés par des dependances classiques que nous règlerons dans le prochain billet à l’aide de OSGI.

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 .

Application WEB vs RCP

Application WEB (client léger) ou client lourd Eclipse RCP? C’est une question que je me pose aujourd’hui. Je ne me permettrais pas de dire que les applications RCP remplaceront les applications WEB, mais je pense que ca vaut le coup de s’interesser à RCP avec l’arrivée de Eclipse E4. Les applications WEB ont pris une ampleur considérable ces dernières années et Javascript a repris une jeunesse avec AJAX qui permet de communiquer avec le serveur avec Javascript via XMLHTTPRequest. Ce dernier permet d’éviter par exemple de rafraîchir toute une page après avoir sélectionné une liste de pays qui doit rafraîchir la liste des villes associées au pays sélectionné, de fournir des fonctionnalités d’aide à la saisie (autocomplétion) qui recherche des informations d’une BD, de charger des images dont on a besoin lorsqu’un utilisateur navigue dans une carte d’une application de cartographie. De nombreux frameworks comme GWT, Struts2, RichFaces (JSF), Wicket, .. propose par défaut des composants AJAX prêts à être employé.

Richesse Interface Utilisateur

Les widgets HTML (champs texte, checkbox…) étant relativement primitives (je ne comprends pas pourquoi W3C ne propose toujours pas des widgets comme le treeview ou la grid dans la norme HTML), Javascript est utilisé pour obtenir des widgets complexes (treeview, grid…). La réalisation de tel composant est complexe, malgré les nombreux frameworks Javascript qui fournissent des widgets prêtes à être employées (Dojo, jQuery…). Développer un composant AJAX (ou uniquement Javascript) est une tâche très côuteuse, ce que je je ne m’imaginais pas avant d’avoir commencer le projet JSControlsTags, qui propose des composants AJAX d’autocompletion, treeview, swap…..Adapter un composant AJAX d’un framework Javascript pour lui ajouter des fonctionnalités manquantes est aussi très compliqué. Une interface utilisateur complexe basée sur Javascript peut souffrir de lenteur, surtout aujourd’hui avec IE6 (qui est malheureusement utilisé dans beaucoup d’institution). En terme de développement, je pense que si on vous donne le choix de développer entre Java et Javascript, le choix est vite fait (GWT permet de gérer son interface utilisateur via des widgets Java, mais son côté boîte noire m’effraie un peu).

Avec RCP les widgets sont riches car SWT (librairies de composants graphiques utilisés dans Eclipse) propose la plupart des widgets utilisés dans une application (comme le treeview (SWT Tree), les grid (SWT Table)…), il est aussi possible d’étendre la biblihothèque en Java pour bénéficier de nouvelles widgets. Nebula est un exemple de projet qui enrichit les widgets SWT.

Déclaration Interface Utilisateur

Dans une application WEB l’interface utilisateur est déclarative via HTML. La présentation (couleur de font, gras, italique…) de l’interface utilisateur peut être déleguée à une feuille de style CSS. Ces 2 solutions couplées est un véritable gain de temps pour la construction d’interfaces utilisateurs (je ne m’étais jamais rendu compte de cela avant d’avoir coder des interfaces Swing ou SWT) et il est possible d’avoir une vue d’ensemble de l’interface utilisateur en lisant le HTML.

Dans une application RCP, SWT est utilisé et la construction d’interfaces utilisateurs est très pénible (les layouts sont par exemple le truc que je déteste le plus). L’un des buts de Eclipse E4 est de simplifier le développement d’interface utilisateur et proposent un moteur CSS (voir examples CSS pour SWT (ou autres) et une solution déclarative (XWT (déclaration de son interface utilisateur via XML) , TM (déclaration de son interface utilisateur via EMF)).

Métier client

Selon l’application à développer, le métier coté client peut est très important. Dans une application WEB, si le métier coté client consiste à effectuer des validations simples (ex : contrôle de validité d’une saisie de date), Javascript peut suffire. Mais si le métier est beaucoup plus complexe, Javascript peut devenir horrible à maintenir. Il est plus judicieux de développer des services de validation coté serveur qui sont ensuite appelés via AJAX par exemple. Mais cette solution nécéssite un appel serveur.

En RCP ce problème n’existe pas, car le client est Java. Il est donc possible d’executer les services de validation coté client.

Robustesse

Dans une application WEB, il est très difficile de maîtriser le cycle de vie du client. Comment détecter par exemple que l’utilisateur ferme son navigateur WEB? Comment détecter qu’il navigue d’une page à une autre via les boutons Suivant/Précédant? Ce manque de maîtrise du cycle de vie du client peut être problématique dans l’application, car par exemple on ne peut pas avertir l’utilisateur que ses données n’ont pas été sauvegardé lors de la fermeture de son navigateur.

Avec RCP, le cycle de vie du client est maitrisée, on peut détecter par exemple que l’application se ferme et effectuer une validation selon l’état de l’interface utilisateur.

Déploiement

En terme de déploiement, une application WEB a l’avantage d’être simple car seul la mise à jour du serveur suffit pour bénéficier d’une nouvelle version de l’applicatiopn. Les client (navigateur WEB ) n’ont pas besoin de se mettre à jour. Avec une application de type client lourd, le déploiement est nécessaire (l’application cliente doit être réinstallée). J’ai entendu parler de P2 (qui remplace depuis Eclipse 3.4, l’Update Manager eclipse qui permet d’installer les plugins) qui apporterait beaucoup, mais je ne suis pas expert. C’est une piste que je souhaiterais aussi étudier.

Conclusion

Je pense que le choix WEB vs RCP doit s’effectuer entre robustesse, maintenance, performance de l’application (coté client) et déploiement de l’application (mais je n’ai pas encore bien étudié P2). Je pense que ca vaut le coup de s’investir aujourd’hui dans OSGI car par exemple la plupart des serveurs (JBoss, Websphere, ….) implémente OSGI du moins en interne. De plus en plus de framework WEB commence à intègrer OSGI (Wicket, Struts2). L’arrivée de Eclipse E4 va permettre aussi beaucoup de chose. Ce sont toutes ces raisons qui me donnent envie de m’investir dans RCP et OSGI. Enfin pour la partie OSGI nous avons fait le choix d’utiliser Spring DM car étant basé sur Spring, nous pouvons bénéficier de la puissance de Spring pour les autres problématiques (IOC, AOP, Spring remoting). Mais je pense qu’il ne faut pas exclure ECF et OSGI Declarative Services.

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/

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.

GEF UndoAction/RedoAction

GEF installe par défaut les actions org.eclipse.gef.ui.actions.UndoAction et org.eclipse.gef.ui.actions.RedoAction dans son registry d’actions, qui permet d’appeler via la CommandStack de l’editor, les méthodes undo/redo de la dernière Command GEF exécutée. Voici le code de la méthode UndoAction#run() :

Et voici la méthode CommandStack#undo() :

Avant d’implémenter les méthodes undo/redo de chacune de nos Command GEF, nous devons appeler les méthodes UndoAction#run() et RedoAction#run() par :

• 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 »

Undo/Redo – Menu Contextuel

Modifiez le code de la méthode WorkflowContextMenuProvider#buildContextMenu(IMenuManager menu) de la classe org.example.workflow.presentation.graphical.actions.WorkflowContextMenuProvider comme suit :

Ici nous ajoutons l’action UndoAction dans le menu contextuel de la page GEF Graphics via le code :

Dans les exemples GEF la constante GEFActionConstants.UNDO est utilisée mais celle-ci est marquée depracated et conseille d’utiliser la constante ActionFactory.UNDO.getId().

Relancez le plugin et vous devez voir apparaître les 2 actions (désactivées) « Undo » et « Redo » dans le menu contextuel :

Undo/Redo – Menu global

Pour lier les entrées de menu « Undo » et « Redo » appartenant au menu globale « Edit », nous allons procéder de la même manière que l’action DeleteAction. Pour cela modifiez la méthode GraphicalWorkkflowActionBarContributor#buildActions() de la classe org.example.workflow.presentation.graphical.actions.GraphicalWorkkflowActionBarContributor comme suit :

Undo/Redo – « Ctrl+Z »/ »Ctrl+Y »

Pour bénéficier du « Ctrl+Z » et « Ctrl+Y » nous n’avons rien à faire car nous avons lier les entrées de menu « Undo » et « Redo » appartenant au menu globale « Edit » qui sont elle-même lié à ces combinaisons de touches.

Command#undo() / Command#redo()

A ce stade les appels de CommandStack#undo() et CommandStack#redo() via le menu contextuel, le menu globale ou « Ctrl+Z », « Ctrl+Y » est opérationnel. Nous pouvons maintenant implémenter les méthodes Command#undo() / Command#redo() pour chacune de nos Command GEF. Par défaut la classe de base org.eclipse.gef.commands.Command implémente la méthode Command#redo() comme ceci :

autrement dit elle appelle la méthode Command#execute(), ce qui dans la plupart des cas fonctionne très bien et évite à la classe qui étend org.eclipse.gef.commands.Command d’implémenter la méthode Command#redo(). La méthode Command#undo() est implémentée comme ceci :

autrement dit elle ne fait rien.

Undo/Redo – CreateCommand

Pour rappel notre classe org.example.workflow.presentation.graphical.commands.CreateCommand s’occupe d’ajouter un state/action aux workflow via sa méthode CreateCommand#execute() :

La méthode CreateCommand#undo() doit effectuer son inverse, autrement dit supprimer le state/action qui a été ajouté au workflow. Pour cela implémentez la méthode CreateCommand#undo() comme ceci :

Ici nous n’avons pas besoin d’implémenter la méthode CreateCommand#redo() car elle est identique à CreateCommand#execute().

Relancez le plugin, ajoutez un state via l’ouil de création de state puis cliquez sur le menu contextuel, l’item « Undo » doit être activé :

Cliquez sur l’item « Undo » pour annuler le state ajouté. Apuyez sur « Ctrl+Y » pour effectuer un Redo par le clavier, le state doit ré-apparaître (ceci permet de vérifier que le menu global est bien opérationnel).

Undo/Redo – ConnectionCreateCommand

Pour rappel notre classe org.example.workflow.presentation.graphical.commands.ConnectionCreateCommand s’occupe de créer une connection entre un state et une action via sa méthode ConnectionCreateCommand#execute() :

La méthode ConnectionCreateCommand#undo() doit effectuer son inverse, autrement dit supprimer la connection. Pour cela implémentez la méthode ConnectionCreateCommand#undo() comme ceci :

Ici nous n’avons pas besoin d’implémenter la méthode ConnectionCreateCommand#redo() car elle est identique à ConnectionCreateCommand#execute.

Relancez le plugin, liez un state et un action à l’aide de l’outil de création de connection puis testez que le undo/redo fonctionne correctement.

Undo/Redo – DeleteCommand

Pour rappel notre classe org.example.workflow.presentation.graphical.commands.DeleteCommand s’occupe de supprimer le state/action selectionné via sa méthode DeleteCommand#execute() :

La méthode DeleteCommand#undo() doit effectuer son inverse, autrement dit ajouter le state/action qui a été supprimé du workflow. Pour cela implémentez la méthode DeleteCommand#undo() comme ceci :

Mias ceci ne suffit pas. En effet ce code fonctionne très bien pour les state/action qui ne sont pas liés par des connections. Dans le cas contraire nous perdons les informations de connections.

Pour gérer le undo correctement, il faut restaurer les connections existantes. Pour cela modifiez le code de DeleteCommand comme suit :

Dans la méthode DeleteCommand#setConnectableNode(ConnectableNode connectableNode) on stocke les connections initialies sources et targets du node :

Puis dans la méthode DeleteCommand#undo() on reconnecte les node en utilisant les connections source et target initialie :

Relancez le plugin et supprimez l’action a1 qui est lié aux states s1 et s2, puis effectuez un « Ctrl+Z », l’action a1 doit être à nouveau lié à s1 et s2.

Undo/Redo – DeleteConnectionCommand

Pour rappel notre classe org.example.workflow.presentation.graphical.commands.DeleteConnectionCommand s’occupe de supprimer une connection entre un state et une action via sa méthode DeleteConnectionCommand#execute() :

La méthode DeleteConnectionCommand#undo() doit effectuer son inverse, autrement dit remettre à jour la connection. Pour cela implémentez la méthode DeleteConnectionCommand#undo() comme ceci :

Relancez le plugin, supprimez un lien entre un state et une action à l’aide de la touche « Suppr », puis testez que le undo/redo fonctionne correctement.

Conclusion

Ici nous avons mis en place les fonctionnalités de Undo/Redo dans la page GEF Graphics. Les Command GEF permettent de gérer le Undo/Redo via la stack de Command. On ne modifie jamais le modèle directement on passe toujours par une Command. EMF.Edit utilise d’ailleurs le même principe. Cependant nous sommes dans un contexte de multi page et le Undo/Redo fonctionne très bien lorsque l’on reste sur une page (ex : on modifie le modèle EMF workflow via la page Graphics GEF, puis on effectue un Undo), mais pas lorsque l’on modifie une page (ex : page Graphics GEF) puis que l’on clique sur une autre page (ex : page Source ou Selection) et que l’on tente d’effectuer un Undo. Ceci s’explique par le fait que chaque page (Selection, Graphics GEF, Source XML) a sa propre stack de command. De plus les Command sont de diiférentes natures :

• la page Selection et Source gère en interne une Command de stack de type Command EMF.
• la page GEF Graphics gère en interne une Command de stack de type Command GEF.

Pour régler ce problème, il faudrait que notre editor multi page partage la même stack de command. Mais la difficulté est que les Command sont de différentes natures. Aujourd’hui je n’ai pas encore étudié cette problématique, mais d’après ce que j’ai pu voir dans JSF Webools, il transforme toutes les Command EMF en Command GEF. Dans leur cas seul la page Source génère des Command EMF :

• la classe org.eclipse.jst.jsf.facesconfig.ui.pageflow.command.EMFCommandStackGEFAdapter qui étent la classe GEF org.eclipse.gef.commands.CommandStack s’occupe de transformer les Command EMF en Command GEF via la classe org.eclipse.jst.jsf.facesconfig.ui.pageflow.command.EMFCommandGEFAdapter. Par exemple elle implémente la méthode GEF org.eclipse.gef.commands.CommandStack#getUndoCommand() comme ceci :
  public Command getUndoCommand() {
    if (emfCommandStack == null || emfCommandStack.getUndoCommand() == null) {
      return null;
    }
      return new EMFCommandGEFAdapter(emfCommandStack.getUndoCommand());
  }

  où emfCommandStack est la stack de command EMF du modèle SSE récupérée comme ceci :

  model = StructuredModelManager.getModelManager().getExistingModelForEdit(doc);
  emfCommandStack = ((BasicCommandStack) this.model.getUndoManager().getCommandStack());

  Un listener est ajouté à la commande de stack EMF :

  emfCommandStack.addCommandStackListener(this);

  pour indiquer à la commande de stack GEF EMFCommandStackGEFAdapter que celle-ci change (ajout d’une nouvelle commande GEF) et qu’elle notifie tous ses listeners GEF org.eclipse.gef.commands.CommandStackEvent qu’il y a un changement dans la stack :

  public void commandStackChanged(EventObject event) {
    this.notifyListeners();
  }
• la classe org.eclipse.jst.jsf.facesconfig.ui.pageflow.command.EMFCommandGEFAdapter étend la classe GEF org.eclipse.gef.commands.Command et attend dans son constructeur une Command EMF
  org.eclipse.emf.common.command.Command. Par exemple elle implémente la méthode GEF org.eclipse.gef.commands.Command#undo() comme ceci :
  public void undo() {
    if (emfCommand == null) {
      return;
    }
    emfCommand.undo();
  }

  où emfCommand est la Command EMF passé dans le constructeur de EMFCommandGEFAdapter.

L’editor multi page FacesConfigEditor travaille toujours avec une stack de Command de type GEF. Si la page activée est celle de GEF, c’est celle de GEF qui est utilisé, si c’est une autre page, c’est EMFCommandStackGEFAdapter qui est utilisé. FacesConfigEditor utilise la classe org.eclipse.jst.jsf.facesconfig.ui.pageflow.command.DelegatingCommandStack qui maintient la stack de Command GEF de la page active. L’état dirty qui doit se baser sur la stack de command GEF de la page active est gérée par le listener GEF org.eclipse.jst.jsf.facesconfig.ui.FacesConfigEditor.MultiPageCommandStackListener qui implémente l’interface GEF org.eclipse.gef.commands.CommandStackListener.

Je pense qu’il est plus difficile (voir impossible) de ne travailler qu’avec des Command EMF, autrement dit transformer les Command GEF en Command EMF car une Command GEF est une classe alors qu’une Command EMF est une interface.

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.

GEF Actions

Dans la page GEF, nous avons vu que notre modèle EMF est modifié via des Command GEF générée par nos EditPolicy installées qui réagissent à l’outil sélectionné dans la palette GEF. Une autre manière est de générer des Command GEF via des actions GEF. Ces actions GEF étendent toutes la classe org.eclipse.jface.action.Action qui sont beaucoup utilisés dans l’IDE Eclipse dans les menu (lorsque l’on clique sur un item d’un menu (ex : Copy), l’item du menu est associé à une Action JFace. La classe de base d’un editor GEF org.eclipse.gef.ui.parts.GraphicalEditor installe dans la méthode GraphicalEditor#createActions() par défaut 3 grands types d’actions GEF:

• les action de selection qui étendent org.eclipse.gef.ui.actions.SelectAction. Ce type d’action génère des Command GEF lorsque le Viewer de GraphicalEditor (GraphicalViewer) est sélectionné, comme l’action de delete.
• les action de stack qui éténdent org.eclipse.gef.ui.actions.StackAction. qui permmettent de gérer le undo, redo…
• les action de properties comme le save (je n’ai pas encore bien compris a quoi sert cette action).

DeleteAction

L’action qui nous intéresse dans notre cas est l’action de selection delete org.eclipse.gef.ui.actions.DeleteAction. Cette action réagit à la selection d’un EditPart et génère une Commande GEF de delete dans le cas ou l’EditPart sélectionné à un EditPolicy qui rèagit à sa suppression (ex : dans notre cas nous installerons un EditPolicy sur les EditPart StateTypePart, ActionTypePart et ConnectionPart pour pouvoir les supprimer.

Lorsqu’un EditPart GEF est sélectionné, une commande GEF DeleteCommand doit être instancié. Ceci est du à la méthode DeleteAction#calculateEnabled() :

Cette méthode est appelée pour vérifier si l’action « Delete » doit être activée ou non. Lorsqu’un EditPart GEF action/state est sélectionné, une commande GEF DeleteCommand devra être instanciée et l’action « Delete » sera activée. L’exéction de la commande GEF DeleteCommand s’effectuera lorsque l’action DeleteAction sera lancée via sa méthode DeleteAction#run() :

GraphicalWorkflowEditor#selectionChanged

Lorsqu’un EditPart GEF est sélectionné, la méthode DeleteAction#calculateEnabled() doit être appelé pour activer/désactiver l’action de delete en fonction de l’EditPart GEF selectionné. Cette méthode est appelé lorsqu’il y a une selection dans le viewer GEF par la méthode GraphicalEditor#updateActions(List actionIds). Le code qui permet de rafraîchir les actions de selection lors d’une selection dans le viewer de l’editor GEF se trouve dans la classe GEF GraphicalEditor :

Cette méthode implémente l’interface org.eclipse.ui.ISelectionListener qui est appelé (théoriquement) lorsque il y a une selection effectuée sur n’importe quel éditeur du workbench Eclipse. GraphicalEditor joue le rôle d’un listener de selection en s’enregistrant dans le service de selection dans sa méthode init :

Le test dans la méthode GraphicalEditor#selectionChanged :

if (this.equals(getSite().getPage().getActiveEditor()))

permet de tester si la sélection effectuée dans l’IDE Eclipse, concerne bien l’editor GEF en question. Dans un contexte ou l’editor GEF n’est pas inclus dans un multi page editor, ce code fonctionne très bien, mais qu’il l’est ce code ne sera jamais éxécuté car :

getSite().getPage().getActiveEditor()

retourne le multi page editor (dans notre cas WorkflowEditor) et pas l’editor GEF qui est inclu dans une page du multi page editor (dans notre cas GraphicalWorkflowEditor). Pour régler ce problème il faut tester si la page courante sélectionnée est bien notre editor GEF. Pour connaître la page active d’un editor, la classe de base org.eclipse.ui.part.MultiPageEditorPart (dont hérite notre multi page editor) fournit la méthode MultiPageEditorPart#getActiveEditor() mais qui est (pour je ne sais quelle raison) en protected. Pour pouvoir y accéder dans notre classe GraphicalWorkflowEditor, nous définissons une nouvelle méthode public WorkflowEditor#getActivePageEditor() comme suit :

Ici nous avons défini une nouvelle méthode (au lieu de surcharger la méthode MultiPageEditorPart#getActiveEditor() protected pour la rendre public) car dans la javdoc il y a :

Subclasses should not override this method.

Nous pouvons ensuite surcharger la méthode GraphicalEditor#selectionChanged(IWorkbenchPart part, ISelection selection) dans la classe GraphicalWorkflowEditor comme suit :

Mettez un point d’arrêt au debut de notre nouvelle méthode GraphicalWorkflowEditor#selectionChanged(IWorkbenchPart part, ISelection selection) et relancez le plugin. Si vous sélectionnez un state dans la page GEF, le point d’arrêt s’arrête.

Delete ActionType-StateType

Pour supprimer un state ou une action du workflow, nous allons créer une Commande GEF org.example.workflow.presentation.graphical.commands.DeleteCommand comme suit :

Cette commande GEF de delete doit être ensuite appelé via un EditPolicy qui doit étendre org.eclipse.gef.editpolicies.ComponentEditPolicy. En effet d’après la javadoc :

By default, ComponentEditPolicy understands being DELETEd from its container….

Notre command GEF DeleteCommand doit être initialisée dans la méthode ComponentEditPolicy#createDeleteCommand(GroupRequest deleteRequest) que nous allons implémenter. Créez la classe org.example.workflow.presentation.graphical.policies.WorkflowComponentEditPolicy comme suit :

Installez l’EditiPolicy WorkflowComponentEditPolicy dans l’EditPart Installez org.example.workflow.presentation.graphical.parts.ConnectableNodePart dans la méthode ConnectableNodePart#createEditPolicies() comme suit :

Executer Commande delete

L’exéction de la commande GEF DeleteCommand s’effectuera lorsque l’action DeleteAction sera lancée via sa méthode DeleteAction#run() :

Il nous reste donc à lancer DeleteAction#run() qui peut s’effectuer de plusieurs manières, autrement dit pouvoir supprimer un state, une action sélectionné :

• par le menu contextuel accéssible dans l’editor GEF Graphics qui propose une entrée de menu « Delete ».
• par la touche « Suppr ».
• par le menu globale accéssible dans la barre de menu standard « Edit » l’entrée de menu « Delete ».

Delete – Menu contextuel

Dans cette section nous allons associer un menu contextuel à la page GEF Graphics et nous y ajouterons une entrée « Delete ». Nous avons vu que l’action de delete GEF DeleteAction est ajouté par défaut au registry d’actions de l’editor GraphicalEditor. Pour ajouter un menu contextuel à une editor GEF, il est conseillé d’implémenter la classe abstraite GEF org.eclipse.gef.ContextMenuProvider.

Créez la classe org.example.workflow.presentation.graphical.actions.WorkflowContextMenuProvider comme suit :

Cette classe éténd org.eclipse.gef.ContextMenuProvider et attend dans son constructeur un registry d’actions (qui sera celui de l’editor GraphicalEditor). La méthode WorkflowContextMenuProvider#buildContextMenu(IMenuManager menu) :

1. appelle GEFActionConstants.addStandardActionGroups(menu); qui ajoute les groupes de menu standards (EDIT, UNDO, COPY…).
2. ajoute l’entrée de menu « Delete » dans le groupe EDIT si l’action « Delete » peut être opérationnel (si une action/state est sélectionné).

Dans les examples GEF, ils utilisent IWorkbenchActionConstants.DELETE pour rechercher l’action de delete, mais cette constante est deprecated, il faut utiliser ActionFactory.DELETE.getId() à la place.

Pour indiquer à notre editor GEF que nous souhaitons utiliser notre menu contextuel WorkflowContextMenuProvider, modifiez la méthode GraphicalWorkflowEditor#configureGraphicalViewer() comme suit :

Relancez le plugin, sélectionnez une action/state et ouvrez le menu contextuel (clic droit de le souris), le menu contextuel doit s’afficher avec une entré de menu « Delete » :

Si vous sélectionnez cette action « Delete », l’action/state selectionné sera ensuite supprimé.

Delete – Touche Suppr

Nous souhaitons executer l’action DeleteAction via la touche « Suppr ». Pour effectuer ceci, il suffit de mapper l’action DeleteAction (identifié par ActionFactory.DELETE.getId()) avec la touche « Suppr » (identifié par SWT.DEL). Définissez la variable de type org.eclipse.gef.KeyHandler dans GraphicalWorkflowEditor qui contiendra notre mapping :

private KeyHandler sharedKeyHandler;

Initialisez le mapping en ajoutant la méthode GraphicalWorkflowEditor#getCommonKeyHandler() :

Pour utilisez notre mapping, ajoutez a la fin de la méthode GraphicalWorkflowEditor#configureGraphicalViewer() le code suivant :

Relancez le plugin, sélectionnez une action/state puis appuyez sur la touche « Suppr » pour le supprimer.

Delete – Menu globale

Nous souhaitons maintenant mapper l’action GEF DeleteActionAction via l’entrée de menu « Delete » du menu globale standard « Edit ». Un EditorPart influe sur les actions disponibles dans la barre de menu en étendant généralement la classe org.eclipse.ui.part.EditorActionBarContributor. Cette barre de menu personnalisée pour l’editor est souvent associée « déclarativement » dans le fichier plugin.xml à l’aide de l’attribut contributorClass. Par exemple dans notre editor de workflow nous avons une entré de menu « Workflow Editor » dans la barre de menu globale qui est disponible lorsque l’editor de workflow est activé. Ce menu est gérée par la classe org.example.workflow.presentation.WorkflowActionBarContributor et est déclaré comme ceci dans le fichier plugin.xml :

GEF fournit la classe abstraite org.eclipse.gef.ui.actions.ActionBarContributor qui éténd org.eclipse.ui.part.EditorActionBarContributor et qui est conseillé d’utiliser pour des actions GEF associées à un editor GEF. Créez la classe org.example.workflow.presentation.graphical.actions.GraphicalWorkkflowActionBarContributor comme suit :

Le code addRetargetAction(new DeleteRetargetAction()); dans la méthode buildActions, mappe l’action de « Delete » du workbench avec l’action DeleteAction GEF.

Maintenant nous devons associer cette barre personnalisée d’actions lorsque la page GEF Graphics est activée. Les exemples GEF renseigne cette barre d’actions déclarativement via l’attribut contributorClass de l’élement XML editor du fichier plugin.xml. Dans notre cas nous ne pouvons pas faire comme ceci car nous sommes dans un contexte de multi page, ce qui signifie que les barre d’actions doivent se rafrîchir aussi en fonction de la page sélectionnée (et pas seulement au niveau de l’editor).

Pour gérer ceci nous allons suivre les explication de la section Completing Menus and Toolbars de l’article GMF ou l’idée générale est de modifier le code EMF pour pouvoir utiliser un org.eclipse.ui.part.MultiPageEditorActionBarContributor qui permet de gérer des barres d’actions selon la page activée dans un editor multi page. Actuellement, l’editor est associé à la barre d’actions org.example.workflow.presentation.WorkflowActionBarContributor qui éténd org.eclipse.emf.edit.ui.action.EditingDomainActionBarContributor

Nous allons créer la classe WorkflowMultipageActionBarContributor (comme TopicmapMultipageActionBarContributor) qui va éténdre org.eclipse.emf.edit.ui.action.EditingDomainActionBarContributor et gérer les barres d’actions de EMF et celle de GEF en fonction de la page activée.

Copiez collez la classe de l’article SubActionBarsExt dans le package org.example.workflow.presentation.

Créez la classe org.example.workflow.presentation.WorkflowMultipageActionBarContributor comme suit :

Modifiez le fichier plugin.xml pour utiliser dans notre editor WorkflowEditor, le contribution de barres d’actions WorkflowMultipageActionBarContributor au lieu de WorkflowActionBarContributor :

Si vous relancez le plugin vous aurrez une erreur de ClassCastException sur WorkflowMultipageActionBarContributor :

Pour eviter cette erreur, modifiez la méthode WorkflowEditor#getActionBarContributor() pour récupérer de notre MultipageActionBarContributor la contribution de barres d’action concernant l’editor SelectionEditPart :

Relancez le plugin (vous n’aurrez plus d’erreur de ClassCastException), selectionnez une action/state et accéder au menu global Edit/Delete :

Cette entrée de menu est active lorsque un state/action est sélectionné. Si vous cliquez sur cette entrée de menu, le state/action sélectionné se supprime du workflow.

Si vous accédez à la page Selection et que vous tentez d’ouvrir le menu contextuel, celui-ci ne s’ouvre pas, pour remédier à ce problème, modifiez la méthode AbstractWorkflowEditorPart#menuAboutToShow(IMenuManager manager) de la classe org.example.workflow.presentation.parts.AbstractWorkflowEditorPart comme ceci :

Relancez le plugin, le menu contentuel dans la page Selection doit être à nouveau opérationnel :

Delete ConnectionType

Pour supprimer une connection nous allons créer une Commande GEF org.example.workflow.presentation.graphical.commands.DeleteConnectionCommand comme suit :

Cette commande GEF de delete de connections doit être ensuite appelé via un EditPolicy qui doit étendre org.eclipse.gef.editpolicies.ConnectionEditPolicy. En effet d’après la javadoc :

A model-based EditPolicy for connections… By default, ConnectionEditPolicy understands only DELETE.

Notre command GEF DeleteConnectionCommand doit être initialisée dans la méthode ConnectionEditPolicy#getDeleteCommand(GroupRequest deleteRequest) que nous allons implémenter. Créez la classe org.example.workflow.presentation.graphical.policies.WorkflowConnectionEditPolicy comme suit :

Installez l’EditiPolicy WorkflowConnectionEditPolicy dans l’EditPart org.example.workflow.presentation.graphical.parts.ConnectionPart dans la méthode ConnectionPart#createEditPolicies() comme suit :

Relancez le plugin, sélectionnez une connection de la page GEF et supprimez la à l’aide du menu contextuel « Delete », à l’aide de la touche « Suppr » ou via le menu global « Edit/Delete ».

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é :

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.

EMF – MultiPageEditorPart

EMF est capable de générer à partir d’un genmodel, un editor multi page MultiPageEditorPart constitué de plusieurs pages capable de mettre à jour un modèle EMF. Un MultiPageEditorPart est un EditorPart constitué de plusieurs pages qui peuvent être :

• un Control SWT qui peut être ajouté au multi page editor via la méthode MultiPageEditorPart#addPage(Control control). Les pages générées par EMF sont basées sur un org.eclipse.emf.common.ui.ViewerPane qui construit en interne un Control SWT (accéssible via la méthode ViewerPane#getControl()) et qui est ajouté à l’editor multi page.
• un EditorPart (ex : notre EditorPart GEF) qui peut être ajouté au multi page editor via la méthode MultiPageEditorPart#addPage(IEditorPart editor, IEditorInput input)

Notre éditor multi page WorkflowEditor en est un exemple d’editor multi page générée par EMF. Dans l’introduction de ce billet nous avons évoqué le problème de selection d’items. Pour regler ce problème nous devons effectuer des modifications du code générée par EMF qui va suivre les étapes décrites dans l’article Integrating EMF and GMF Generated Editors. Le lien Integrating EMF / GMF editors article – comments est un commentaire effectué sur cet article qui est aussi très intéressant de lire.

L’idée générale des modifications à effectuer dans le code générée par EMF est :

• d’utiliser un MultiPageSelectionProvider au lieu de l’implémentation de ISelectionProvider générée par EMF (le WorkflowEditor lui même).
• Le MultiPageSelectionProvider impose le fait d’avoir des EditorPart, ce qui implique de transformer les ViewerPane EMF en EditorPart.

Dans ce billet je vais suivre les mêmes étapes que l’article Integrating EMF and GMF Generated Editors :

• Dissecting the EMF Editor qui permettra d’utiliser des EditorPart au lieu des ViewerPane.
• Selection Handling qui permettra d’utiliser un MultiPageSelectionProvider au lieu des WorkflowEditor qui implémente ISelectionProvider.
• Combining the Editors qui corrigera le problème de la synchronisation de la page Selection avec la Outline.

Dissecting the EMF Editor

Ici nous allons effectuer la même chose que ce qui est expliqué dans la section Dissecting the EMF Editor de l’article GMF. L’idée est de ne plus utiliser les ViewerPane EMF mais d’utiliser les EditorPart. En effet nous souhaitons utiliser un MultiPageSelectionProvider dans notre editor, ce qui implique que chacune des pages doivent être des EditorPart (et pas des Control SWT). Le code MultiPageSelectionProvider#getSelection()

montre que ce ISelectionProvider fonctionne qu’avec des IEditorPart.

Nous allons transformer uniquement la page Selection basée sur un ViewerPane en EditorPart. Les autres pages n’existeront plus dans notre editor. Mais nous allons quand même créer une classe de base (basé sur EditorPart) qui gère la plupart des problèmetque du ViewerPane, si jamais vous souhaitez ajouter les autres pages dans votre cas (je vous conseille de regarder l’article qui explique comment faire). Cette classe de base est identique (presque) à TopicmapEditorPart expliqué dans l’article.

Créer la classe org.example.workflow.presentation.parts.AbstractWorkflowEditorPart comme suit :

Créer la classe org.example.workflow.presentation.parts.SelectionEditorPart comme suit :

Cette classe gère la même chose que la page Selection basé sur un ViewerPane.

Dans la classe WorkflowEditor, définissez un champs selectionEditorPart

private SelectionEditorPart selectionEditorPart;

Dans la méthode WorkflowEditor#createPages() supprimez tout le code qui utilise les ViewerPane et remplacez le par le code suivant :

Nous pouvons maintenant supprimer les méthodes WorkflowEditor#setCurrentViewerPane(ViewerPane viewerPane) et WorkflowEditor#setFocus(). La ré-implementation de WorkflowEditor#isDirty() peut être aussi enlevée.

Selection Handling

A cette étape si vous relancez le plugin et que vous sélectionnez un state, action dans le Treeview de la page Selection, la vue Properties n’est pas rafraîchit correctement. La selection d’items ne fonctionnent plus. Ici nous allons effectuer la même chose que ce qui est expliqué dans la section Selection Handling de l’article GMF. L’idée est d’utiliser un MultiPageSelectionProvider en tant que ISelectionProvider au lieu du WorkflowEditor lui même (qui implémente ISelectionProvider).

Dans la classe WorkflowEditor, ajoutez le champs de type org.eclipse.ui.part.MultiPageSelectionProvider :

private MultiPageSelectionProvider selectionProvider;

Modifiez le constructueur de WorkflowEditor comme suit :

Ce code permet d’instancier le MultiPageSelectionProvider. Un listener est branché dessus pour détecter les changement de selection (ex : selection d’un item du Treeview de la page Selection, selection d’un EditPart GEF) et afficher le resultat de la selection dans la barre de statut (en bas à gauche du workbench).

WorkflowEditor ne doit plus implémenter ISelectionProvider :

Maintenant nous pouvons supprimer tout le code qui implémente l’interface ISelectionProvider : supprimez les champs selectionChangedListener, selectionChangedListeners et editorSelection et supprimez les méthodes WorkflowEditor#addSelectionChangedListener(ISelectionChangedListener listener) WorkflowEditor#removeSelectionChangedListener(ISelectionChangedListener listener), WorkflowEditor#getSelection() et WorkflowEditor#setSelection(ISelection selection).

Commentez dans la méthode WorkflowEditor#handleChangedResources() le code suivant :

L’utilisation du ISelectionProvider s’effectue via le IEditorSite. Modifiez le code de la méthode WorkflowEditor#init(IEditorSite site, IEditorInput editorInput) pour pouvoir utiliser notre MultiPageSelectionProvider :

Pour information, Un EditorPart possède un org.eclipse.ui.IEditorSite qui joue le rôle d’interface entre le workbench et un editor part. IEditorSite est accessible via la méthode EditorPart#getSite() (plus exactement WorkbenchPart#getSite()). C’est à travers IEditorSite que l’on renseigne par exemple :

• les menu contextuels (registerContextMenu) disponibles dans l’EditorPart.
• les actions disponibles (getActionBars) dans le menu globale du workbench (lorsque l’editor est sélectionné).
• le fournisseur de selection org.eclipse.jface.viewers.ISelectionProvider de l’editor via la méthode EditorPart#setSelectionProvider(ISelectionProvider provider).

Modifiez la méthode WorkflowEditor#handleActivate() pour pouvoir utiliser notre MultiPageSelectionProvider :

Modifiez WorkflowEditor#setCurrentViewer(Viewer viewer) qui n’a plus besoin de gérer la selection (branchement/débranchement des listener ISelectionChangedListener) :

Relancez le plugin et assurez vous que la vue Outline n’est pas ouverte, maintenant lorsque vous sélectionnez un EditPart GEF dans la page Graphics, la selection de ce dernier doit s’afficher dans le barre de statut :

Vous pouvez aussi vérifier que lorsque vous sélectionnez un item du Treeview dans la page Selection, la selection doit aussi s’afficher dans la barre de statut.

Combining the Editors

Ouvrez la vue Outline via le menu Window/Show view/Outline, mettez vous sur la page Selection, puis sélectionnez un item de la Outline. Le Treeview de la page Selection, n’est pas synchronisé avec la vue Outline :

Le problème vient de la méthode WorkflowEditor#handleContentOutlineSelection() qui teste entre autre si la variable currentViewerPane n’est pas null. Dans notre cas elle est toujours null (car elle était mise à jour par le code générée que nous avons supprimé).

Ici nous allons effectuer la même chose que ce qui est expliqué dans la section Combining the Editors de l’article GMF

Pour régler ce problème, supprimez le champs currentViewerPane

 //protected ViewerPane currentViewerPane;

et modifiez le code comme suit :

Ce code gère la selection de la page Selection et des autres pages qui hériterait de AbstractWorkflowEditorPart. Ici nous ne gerons ni la page source, ni la page Graphics. Relancez le plugin et vous pourrez constater que la Treeview de la page Selection est synchronisée avec le Treeview de la vue Outline :

GEF – Selection EdiPart

Les modifications de code sont finies dans ce billet. Dans cette section je vais tenter d’expliquer le problème de selection d’EditPart GEF avec le code générée par EMF.

GEF GraphicalViewer – ISelectionProvider

Nous avons modifié le code pour utiliser MultiPageSelectionProvider (et plus que WorkflowEditor implémente ISelectionProvider). Mais pourquoi devons nous faire ca? Ici je vais tenter d’expliquer pourquoi l’utilisation de MultiPageSelectionProvider règle le problème de selection des EditPart GEF.

Lorsqu’un EditPart GEF est sélectionné (clic de la souris sur un state, action, connection de la page Graphics GEF), le viewer GEF GraphicalViewer associé à l’editor GEF GraphicalEditor est capable de détecter l’EditPart sélectionné et notifie les listeners qui ont été préalablement enregistrés qu’un/plusieurs EditPart a/ont été sélectionnés. Le viewer GEF joue le rôle d’un fournisseur de sélection (il implémente l’interface org.eclipse.jface.viewers.ISelectionProvider) sur lequel on peut brancher des listeners org.eclipse.jface.viewers.ISelectionChangedListener qui souhaitent être informés des EditPart sélectionnés.

La méthode qui nous intéresse pour comprendre le probléme de selection dans GEF engendré par le code générée EMF est AbstractEditPartViewer#fireSelectionChanged() de la classe org.eclipse.gef.ui.parts.AbstractEditPartViewer :

Cette méthode est appelée dès qu’un ou plusieurs EditPart GEF sont sélectionnés et appelle pour chacun des listeners qui implémente la méthode ISelectionChangedListener#selectionChanged(SelectionChangedEvent event) de l’interface ISelectionChangedListener. Si vous mettez un point d’arrêt dans la méthode AbstractEditPartViewer#fireSelectionChanged(), vous pourrez constater que 2 listeners ISelectionChangedListener sont enregistrés :

• org.eclipse.gef.ui.parts.SelectionSynchronizer : qui d’après la javadoc GEF est utilisé pour synchroniser les selection entre plusieurs viewer GEF (ce qui n’est pas notre cas).
• org.eclipse.ui.part.MultiPageEditorSite : qui est l’IEditorSite de notre multi page editor. Plus exactement c’est la méthode privée MultiPageEditorSite#getSelectionChangedListener() qui joue le rôle de listener.

Le listener qui nous intéresse est le deuxième (MultiPageEditorSite). Voici le code de MultiPageEditorSite#getSelectionChangedListener() :

Lorsqu’une selection d’un EditPart GEF est effectuée, le méthode MultiPageEditorSite#handleSelectionChanged de la classe MultiPageEditorSite est appelée. Voici son code :

Le test qui nous intéresse est

if (parentProvider instanceof MultiPageSelectionProvider) ...

Il vérifie que le fournisseur de sélection du multi page editor (dans notre cas WorkflowEditor) est de type MultiPageSelectionProvider. Ce test n’est jamais vrai avec le code générée par EMF car le fournisseur de selection le multi page WorkflowEditor lui-même. En effet si on regarde le code générée par EMF de notre multi page editor WorkflowEditor, cette dernière implémente ISelectionProvider

et indique que le fournisseur de selection de son IEditorSite (qui est un MultiPageEditorSite) est lui-même dans la méthode WorkflowEditor#init(IEditorSite site, IEditorInput editorInput) :

Par défaut un MultiPageEditorPart utilise un MultiPageSelectionProvider mais le code générée par EMF n’utilise pas de MultiPageSelectionProvider ce qui rtend obsolète la sélection des EditPart GEF.

GEF GraphicalEditor – ISelectionChangedListener

Après avoir modifiez le code pour pouvoir utiliser un MultiPageSelectionProvider, mettez un point d’arrêt dans la méthode GraphicalEditor#selectionChanged#selectionChanged(IWorkbenchPart part, ISelection selection), et vous pourrez constater que le point d’arrêt s’arrête :

Si on regarde la trace on peut voir que la méthode MultiPageSelectionProvider#fireSelectionChanged() est appelé qui appelle la méthode MultiPageSelectionProvider#fireEventChange(final SelectionChangedEvent event, Object[] listeners) :

La méthode fireEventChange :

itère sur la liste des listeners enregistrés.

Le listener qui nous intéresse est le service de selection (AbstractSelectionService) qui est enregistré dans les listeners et qui appelle la méthode GraphicalEditor#selectionChanged#selectionChanged(IWorkbenchPart part, ISelection selection),.

GEF utilise le service de selection. Le GraphicalViewer GEF jour le rôle du fournisseur de selection ISelectionProvider et l’editor GEF GraphicalEditor jour le rôle du consommateur de selection (ISelectionChangedListener). Ce dernier s’abonne au service de selection dans sa méthode init :

Pour plus d’information sur l’utilisation du service de selection je vous conseille de lire l’article Eclipse Workbench: Using the Selection Service.

L’editor GEF GraphicalEditor enregistre le fournisseur de selection GraphicalViewer via le MultiPageEditorSite comme ceci :