Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step2]

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.dynaresume.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.dynaresume.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.dynaresume_step2.zip présentés dans ce billet.

I .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à.

I-A .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.

I-B .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.

I-C .Récapitulatif

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

Serveur JEE	OSGi
Spécification Serveur JEE (conteneur)	Spécification Conteneur OSGi
Implémentation Serveur (Tomcat, Jetty…)	Implémentation conteneur OSGi (Equinox, Felix, …)
Application WEB (WAR)	Bundle OSGi (JAR)
JAR dans common/lib (pour Tomcat) et dans WEB-INF/lib du WAR	JARs installés dans le conteneur et ceux embarqués par le bundle
Interface javax.servlet.*	Interface org.osgi.framework.*
Implémentation interfaces JEE par le Serveur (Tomcat, Jetty…)	Implémentation interfaces OSGi par le conteneur OSGi (Equinox, Felix,…)
distribuable sous forme *.war	distribuable sous forme *.jar

II .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.dynaresume.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.

II-A .Création Bundle

Ici nous allons créer le Bundle (projet Plug-in) org.dynaresume.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.dynaresume.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 DynaResume 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.
• 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.

II-B .Contenu Bundle créé

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

II-C .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.

II-D .BundleActivator

PDE à généré la classe org.dynaresume.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 :

package org.dynaresume.domain;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

	/*
	 * (non-Javadoc)
	 * @see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)
	 */
	public void start(BundleContext context) throws Exception {
	}

	/*
	 * (non-Javadoc)
	 * @see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)
	 */
	public void stop(BundleContext context) throws Exception {
	}

}

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.dynaresume.domain.Activator, ceci s’effectue via la méta donnée Bundle-Activator du fichier MANIFEST.MF comme ceci :

Bundle-Activator: org.dynaresume.domain.Activator

La classe org.dynaresume.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 :

...
Bundle-SymbolicName: org.eclipse.osgi; singleton:=true
Export-Package: ...
org.osgi.framework;version="1.5"
...

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

Export-Package: ...
org.osgi.framework;version="1.5"
...

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

II-E .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

II-E-1 .Import-Package

La gestion de dépendances de notre Bundle org.dynaresume.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.dynaresume.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.

II-E-2 .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

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

III-A .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.

III-B .Onglet Dependencies

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

III-B-1 .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.dynaresume.domain doit toujours compiler.

III-B-2 .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).

III-C .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 :

III-D .Onglet MANIFEST.MF

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

IV .Lancement de notre 1er Bundle

A cette étape nous souhaitons lancer notre Bundle org.dynaresume.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 :

soit :

osgi> org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment: JavaSE-1.6
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)


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.dynaresume.domain a le status ACTIVE, ce qui signifie que tout s’est bien passé.

IV-A .Run

A cette étape nous pouvons lancer notre Bundle. Si vous ne souhaitez pas paramétrer la Target Platform, importer le launch OSGi DynaResume.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 DynaResume.

IV-B .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 DynaResume 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 liste des bundles à diminuée (dans les version Eclipse JEE, les Bundles (Plug-In) de Eclipse sont décochés) :

V .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.dynaresume.domain.Activator pour tracer le démmarage (start) et l’arrêt (stop) de notre Bundle org.dynaresume.domain. Pour cela modifier le code de cette classe comme suit :

package org.dynaresume.domain;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

	/*
	 * (non-Javadoc)
	 * @see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)
	 */
	public void start(BundleContext context) throws Exception {
		System.out.println("Start Bundle [" + context.getBundle().getSymbolicName() + "]");
	}

	/*
	 * (non-Javadoc)
	 * @see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)
	 */
	public void stop(BundleContext context) throws Exception {
		System.out.println("Stop Bundle [" + context.getBundle().getSymbolicName() + "]");
	}

}

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

osgi> Start Bundle [org.dynaresume.domain]

Notre méthode org.dynaresume.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 :

0 ACTIVE org.eclipse.osgi_3.5.0.v20090520
7 ACTIVE org.dynaresume.domain_1.0.0.qualifier

Notre Bundle org.dynaresume.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 :

osgi> stop 7
Stop Bundle [org.dynaresume.domain]

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

Saisissez dans la console start 7

La consle OSGi affiche :

osgi> start 7
Start Bundle [org.dynaresume.domain]

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 :

osgi> stop 0
osgi> Stop Bundle [org.dynaresume.domain]

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

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

ss
Exception in thread "OSGi Console" java.lang.IllegalStateException: BundleContext is no longer valid
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.checkValid(BundleContextImpl.java:1000)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:657)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.getServices(FrameworkConsole.java:377)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:300)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:288)
at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:224)
at java.lang.Thread.run(Unknown Source)

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

VI .OSGi DynaResume.launch

VI-A .Import Launch

Dans le zip org.dynaresume_step2.zip vous trouverez un fichier OSGi DynaResume.launch qui est un export du launch OSGi DynaResume 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 DynaResume.launch du zip :

Cliquez sur le bouton Finish pour importer le launch. Cet import a créé le launch OSGi DynaResume 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 DynaResume 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.

VI-B .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 DynaResume puis sur le bouton Finish pour exporter ce launch dans un fichier OSGi DynaResume.launch :

VII .Conclusion

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

Vous pouvez lire le billet suivant [step3].