Discussion :

[scorbo]

Bonjour

Dans le cadre du développement d'une application utilisant OSGi, je m'interroge sur une partie de l'architecture.
Dans l'application il peut y avoir un bundle de type "logger". Ainsi d'autres bundles peuvent venir écrire des messages s'ils le désirent ("ouverture du fichier", "analyse en cours...", etc.).
OSGi oblige, il n'est pas certains que le bundle "logger" soit présent dans l'application.

La première solution consisterait à ce que chaque bundle vérifie la présence d'un "logger" avant de l'utiliser. Ce que je trouve un peu lourd (recherche du bundle dans le context + vérification si non null, et ce avant chaque message). Pour centraliser cette vérification chaque développeur de bundle pourrait écrire une classe dans leur bundle pour logger, du coup dans chaque bundle voulant logger il y a une part de code commune. Je me demande s'il n'est pas possible de la capitaliser ailleurs.

Afin de capitaliser et alléger le travail des développeurs de bundle, il serait possible de passer à chaque bundle, souhaitant logger, une interface permettant de le faire. Du coup le code serait capitaliser dans l'implémentation de cette interface. Par contre je me dis que le bundle devient fortement lié à un autre bundle juste pour logger des messages et ne pourra même pas démarrer sans ce dernier (ne pas démarrer juste pour une histoire de logger c'est un peu rude... ).

Quelle solution est préférable ? Il y a-t-il une autre solution ?

Merci

[Cafeinoman]

Si tu peux utiliser java 8, le plus simple serait effectivement de fournir l'interface, mais avec des méthodes default, qui envoient vers System.out par exemple. Et si un Bundle de log est présent, la tuyauterie renvois vers lui...

[tac.p]

Bonjour,

Question, as-tu des raisons de penser que le bundle contenant le Logger disparaisse de ta plateforme OSGi en cours d'exécution, si il est présent à un moment donné dans ton application ?

Si oui, alors j'aurai 2 options similaire à ce que tu as décrit, Option 1: avant chaque Log, je vérifie si il y a un Logger dans le contexte du Bundle, Option 2: lorsque je "startup" un composant utilisant un Logger, j'enregistre un ServiceTracker qui vérifie les apparitions disparitions du Service Logger et permet ainsi de Logger.

Si non, je me contenterai d'avoir dans chacun des mes composants une méthode getLogger() qui la première fois qu'elle est appelée vérifie si il y a un Logger dans le contexte du Bundle, et si elle le trouve le place dans un champ qui est utilisé pour les appels suivants, un peu comme tu ferais un getInstance() dans un Singleton (c'est moins lourd qu'un ServiceTracker et tu ne fais l'appel au ServiceRegister qu'une seule fois).

Pierre

[scorbo]

Cafeinoman : En effet, je n'avais pas pensé à cette nouvelle fonctionnalité dans Java 8, c'est une possibilité. Techniquement rien ne m'empêche d'utiliser Java 8, mais perso je préfère encore rester un peu sur du Java 7 et attendre un peu que le 8 soit bien présent partout.

tac.p : non, actuellement je n'ai pas de raisons de penser que le bundle Logger disparaisse en cours de route. Par contre si je commence à me dire ça des bundles, je vais à l'encontre des principes de base d'OSGi.

[Tcharl]

Hello,

Je dirais qu'on fait comme en Java lors d'un lookup, on null check après avoir retrouvé la référence (ce que tu as expliqué en premier), a mettre dans une méthode dans l'activateur de chacun de tes bundle (que tu devras transformer en singleton).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
ServiceReference<LoggerService> logServiceRef = context.getServiceReference(LoggerService.class);
LoggerService log = context.getService(logServiceRef);
if (null != log) {
log.error("aie");
}

Ceci ne loguera pas si tu a un bundle SPI (service provider interface) de log encore actif, et un service d'implémentation tombé. Et encore, ça ne gérera pas le cas où tu as plusieurs implémentations: ça prendra le premier (avec quelques modifications dans le code, ça pourra loguer dans tous)!
Tu peux aussi faire un ServiceTracker pour suivre les apparitions/disparitions des différents LoggerServices...

Après, si tu abstrais ce code (avec un 'MyCompanyActivator' que tous les activateurs étendent), tes bundles vont tomber si ton superbundle tombe...

Enfin il ne faut pas être pessimiste, c'est à l'utilisateur de démarrer ou arrêter les jars, la machine n'a aucune raison de la faire elle même.