Tag Archives: osgi

Retrouver le bundle auquel appartient une classeGiven a class, how to retrieve its bundle?

OSGI R4.2 (donc Equinox 3.5) introduit une nouveauté toute bête, mais particulièrement pratique. Il s’agit de la méthode org.osgi.framework.FrameworkUtil.getBundle(Class), qui permet de récupérer le bundle auquel appartient une classe donnée.

Plus précisément, cette méthode vous renverra le bundle qui a servi à résoudre ladite classe, ou null dans le cas où la classe n’a pas été chargée par le Framework (si c’est une classe du boot classpath par exemple…).

Ainsi, dès qu’il s’agira de récupérer des infos comme le numéro de version d’un bundle, ses headers, etc… sans avoir à passer par l’Activator (qui parfois n’existe d’ailleurs même pas…), vous savez ce qu’il vous restera à faire! En outre, qui dit Bundle, dit BundleContext, et cette méthode est donc également un moyen très simple de publier/consommer des services !.. 🙄OSGI R4.2 (thus Equinox 3.5) comes (well, will come, since the spec. is not final yet) with a new simple and handy utility: the org.osgi.framework.FrameworkUtil.getBundle(Class) static method, which allows to retrieve the bundle a given class belongs to.

More specifically, this method will give you the bundle who loaded the given class, or null if the class has not been loaded by the OSGi framework (e.g. if it is a class belonging to the boot classpath…).

Thus, whenever you want to access information such as the version of a bundle, its headers,  etc. without having to query its Activator (perhaps you don’t even have an Activator for this bundle…), you know what you’ve got to use! Of course, whoever says Bundle, means BundleContext, and this handy helper is also very convenient to easily publish/consume OSGi services on behalf of the bundle… 🙄

Fiche de référence OSGi

Equinox & OSGiEn guise d’avant-goût au livre “Equinox and OSGi: The Power Behind Eclipse“, une fiche de référence sur OSGi et son implémentation de référence Equinox a été concoctée par Jeff McAffer et mise à disposition sur le site DZone.

Attention, il faut un compte pour pouvoir télécharger le PDF —et je n’ai pas le droit de le mettre à disposition ici 😉 .

En 6 pages, Jeff fait le tour de tous les concepts de base d’OSGi/Equinox, et répond à des questions que tout développeur de bundles OSGi (et plus généralement de plug-ins Eclipse) s’est un jour posé :

  • Faut-il préférer l’en-tête Import-Package à Require-Bundle pour la gestion des dépendances?
  • Quelle sont les différences entre les services OSGi, les declarative services et les extensions Eclipse? 
  • Comment manipuler ses bundles depuis la console OSGi?
  • etc. 😉

A lire absolument!

OSGi en bref : La directive singleton

En développant vos plug-ins, vous avez peut-être un jour été confronté à une erreur, à première vue obscure, due à une directive singleton soit disant manquante…
En effet, le PDE lève une erreur lorsqu’un plug-in qui n’est pas “singleton” souhaite définir des extensions ou des points d’extension.

Pourquoi, et qu’est-ce au juste que cette directive  ?

Bundle-SymbolicName: com.acme.module.test; singleton:=true

Dans la norme OSGi, il est indiqué que “singleton” (renseigné dans l’entrée de MANIFEST Bundle-SymbolicName) doit être placé à true lorsque l’on souhaite interdire la résolution par le framework de plusieurs versions d’un même bundle.

C’est donc tout à fait logique qu’un plug-in amenant des extensions ou des points d’extension soit impérativement un singleton ; car il serait sans cela très difficile, voire impossible, de gérer les différentes versions résolues au runtime…
Imaginez simplement un plug-in amenant une vue, que l’on pourrait déployer dans deux, trois, … versions différentes au sein du même Eclipse : à quoi devrait-on s’attendre lors de l’affichage du menu “Show View > Other…” ???

Dans le cas où on écrit un plug-in n’amenant ni extension ni point d’extension —un plug-in de librairies, par exemple—, on sera en revanche ravi de pouvoir dire que ce n’est pas un singleton (c’est le comportement par défaut), et ainsi faire coexister différentes versions de nos librairies dans le même Eclipse. C’est d’ailleurs exactement ce qui se passe avec les plug-ins ICU, Ant ou log4j, dont les utilisateurs viennent dépendre en venant préciser le numéro (ou l’intervalle) de version qui les intéresse…