Calculer Girl
  1. Calculer Girl
  3. Dans OSGi, ServiceLoader.load ne parvient pas à trouver une implémentation
Intereting Posts
wget: nom du fichier téléchargé Planificateur de tâches Windows pour exécuter des tâches en quelques secondes Impossible d’append PPA: ‘ppa: ondrej / php5-5.6’ Des outils pour connaître la disposition (segments) du processus en cours dans Windows? Comment faire un programme de ligne de commande Linux sous Windows? tcpdump sur l’interface en mode moniteur – rien capturé Lookaheand & Lookafter dans grep dans le terminal unix Trace des programmes exécutés appelés par un script Bash résultat de sys_get_temp_dir () non accessible en écriture par l’utilisateur du processus Apache Comment trouver l’adresse MAC par programmation sur IRIX? PHP exec commande pgp ksh split ssortingng à un tableau à écrire dans un fichier .htaccess, réécriture du nom de fichier avec le même nom que le répertoire Comment lire un stream audio sécurisé HTTPS avec authentification de base à l’aide du lecteur audio HTML5 mod_rewrite ne fonctionne pas comme proxy interne

Dans OSGi, ServiceLoader.load ne parvient pas à trouver une implémentation

Nous avons essayé de faire fonctionner SPI Fly avec openstack4j-core et l’un des connecteurs openstack4j ( openstack4j-httpclient ). C’est org.openstack4j.core.transport.HttpExecutorService qui nécessite le tissage SPIFly.

Une quirk: les deux bundles sont chargés depuis un fichier zip et démarrés une fois que le rest du système est opérationnel. Le même fichier zip fournit org.apache.aries.spifly.dynamic.bundle .

Les deux bundles utilisent le modèle compatible OSGI-Spec du jeu d’instructions standard pour SPI Fly . Selon ces instructions, tout ce dont nous avons besoin, ce sont les en Provide-Capability têtes Require Require-Capability et Provide-Capability appropriés dans MANIFEST.MF des deux bundles, ainsi que la déclaration de service sous META-INF / (illustrée ci-dessous).

Le kernel a: 

 Require-Capability: osgi.serviceloader;filter:="(osgi.serviceloader=org.openstack4j.api.APIProvider)";cardinality:=multiple, osgi.serviceloader;filter:="(osgi.serviceloader=org.openstack4j.core.transport.HttpExecutorService)";cardinality:=multiple, osgi.serviceloader;filter:="(osgi.serviceloader=org.openstack4j.openstack.logging.LoggerFactorySupplier)";cardinality:=multiple;resolution:=optional, osgi.extender;filter:="(osgi.extender=osgi.serviceloader.processor)", osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)", osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"

Et le httpclient a: 

 Require-Capability: osgi.extender;filter:="(osgi.extender=osgi.serviceloader.registrar)",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))" Provide-Capability: osgi.serviceloader;osgi.serviceloader="org.openstack4j.core.transport.HttpExecutorService"

(Re-formaté pour la lisibilité, bien sûr)

En outre, le fichier openstack4j-httpclient contient le fichier org.openstack4j.core.transport.HttpExecutorService sous META-INF / services , avec une seule ligne: 

 org.openstack4j.connectors.httpclient.HttpExecutorServiceImpl

Nous ajoutons également le org.apache.aries.spifly.dynamic.bundle , qui fournit les fonctionnalités serviceloader.processor et serviceloader.registrar .

Ensuite, à l’exécution, l’appel ServiceLoader ne trouve tout simplement pas le HttpExecutorService .

PS: le traitement de l’ordre dans lequel les bundles ont été lancés n’a pas été fructueux et l’appel de resolveBundles sur FrameworkWiring avant le resolveBundles de tous les bundles n’a pas fonctionné.