OSGi et gestion des composants

Question

J'ai une application dynamique qui utilise OSGi pour charger des fonctionnalités modulaires lors de l'exécution. Les bundles OSGi contiennent la fonctionnalité modulaire et l'application charge les bundles lorsqu'ils sont nécessaires. Cette approche fonctionne bien, mais je voudrais une solution plus granulaire. Les bundles contiennent des composants contrôlés par le biais des services déclaratifs. J'aimerais pouvoir charger un paquet et activer uniquement les composants nécessaires dans le bundle. J'ai fait des recherches dans ce domaine, mais je ne trouve pas de solution satisfaisante. Une approche consistait à créer un composant "gatekeeper" qui est toujours activé dans le bundle et à travers ComponentContext, il laisse l'appel activer et désactiver le composant. C'est une solution viable, mais je ne pouvais pas trouver un moyen pour le «portier» de «connaître» les autres composants du bundle sans coder en dur les noms des composants en tant que propriétés dans le descripteur SCR xml «gatekeepers».

Ce que je préfère est un moyen de charger des paquets et de "connaître" tous les composants dans les paquets chargés. Être capable de déterminer dans quel paquet se trouvent les composants et dans quel état ils se trouvent (similaire à la commande 'ls' de la console equinox qui liste tous les composants). Je voudrais activer et désactiver les composants si nécessaire.

Comment est-ce que la console fait ceci et comment pourrais-je faire ceci dans une application?

Mise à jour: @Neil Bartlett: Désolé pour le retard. Je devais passer à autre chose. Maintenant, je suis de retour sur cette question. Vraiment apprécierait toute aide supplémentaire. Mon application est basée sur le rôle. Je dois activer les composants en fonction de la fonctionnalité qu'ils fournissent. L'objectif est que tous les composants basés sur les rôles soient initialement désactivés. Lors d'un changement de rôle, un gestionnaire de rôles interroge chaque composant pour connaître la fonctionnalité fournie et détermine s'il faut le charger. Chaque composant diffusera les fonctionnalités qu'il fournit (via une interface de service commune). ScrService ne me permettra pas d'activer un composant de service initialement désactivé. L'activation initiale des composants et le fait que ScrService les désactive le plus tôt possible au démarrage de l'application ne correspondent pas à mes besoins.

Answer 1

Jetez un oeil à ScrService. Bothe équinoxe et Felix l'a. Cependant, les composants peuvent être amenés à se charger paresseusement, c'est-à-dire uniquement lorsque cela est nécessaire pour d'autres composants/faisceaux; mais ce n'est peut-être pas ce que vous voulez.

Answer 2

Dans la description de votre service, marquez les composants comme étant activés, mais nécessitant des informations de configuration fournies par le service de gestion de la configuration. vous pouvez alors écrire un service plugin CM (je ne me souviens pas du terme exact) qui peut publier et modifier la configuration de vos composants. Les services par défaut sont identifiés par leur nom, qui est leur nom de classe d'implémentation par défaut. Les données de configuration sont transmises sous forme de carte et peuvent être vides. DS rendra le service disponible dès que le câblo-modem aura fourni une configuration.

Answer 3

J'ai un problème similaire, mais dans un but différent: - J'ai une installation de fichier apache et un service d'administration de configuration pour configurer mes composants en externe avec des fichiers de propriétés. - J'avais besoin de m'assurer que certains composants obtiennent la config du fichier externe et la seule façon que j'ai trouvée jusqu'ici est que je marque mes composants avec ConfigurationPolicy.REQUIRED. - Mais de cette façon, mon projet de plugin ne s'exécute pas dans eclipse (où il n'y a pas de fichiers de configuration). - Le fichier component.xml contient également une configuration de développement par défaut, donc je suis d'accord avec ça, juste mon composant ne démarre pas tant qu'il n'y a pas de données de configuration disponibles avec configadmin. Mes composants sont insatisfaits de cette façon, jusqu'à ce que quelqu'un crée une entrée configadmin. - J'ai compris que si je crée un extendeur de ligne de commande osgi qui envoie des configurations vides au service pid, il démarrera avec les valeurs par défaut dans les fichiers component.xml. - Je suis juste venu ici pour trouver un moyen de lister tous les paquets

Mais je pense que cette solution que j'utilise peut aussi fonctionner avec votre configuration et c'est pourquoi j'écris ceci. Marquez simplement tous vos composants à l'aide de la commande configuretationpolicy.require et vous pouvez les démarrer et les arrêter de manière sélective en ajoutant et en supprimant des configurations avec configadmin. Cela peut être difficile si vous utilisez déjà la configadmin à d'autres fins, mais cela peut être gérable en dernier recours.