Javax.ImageIo.Spi.ServiceReGistry travaille-t-il dans un conteneur OSGI?

Question

Quelqu'un peut-il me dire définitivement si un paquet OSGI contenant du code qui appelle

Javax.ImageIO.SPI.ServiceRégie

Pour trouver un service (dans Meta-Inf \ Service) trouvera ce service, si cette implémentation de service est dans un autre paquet.

Je ne trouve aucune documentation spécifique à ce sujet.J'utilise le conteneur Felix Osgi.Tous les pointeurs seraient reçus avec gratitude.

Je soupçonne que cela fonctionne et que mon problème réside ailleurs, car je remarque que dans le Xdocort Osgi Bundle fr.opensagres.xdocreport.core, ServiceRegistry est utilisé ici maisPeut-être que ce n'est pas pris en charge sur tous les conteneurs OSGI?

Answer 1

Bonjour merci à tous pour vos réponses. Je pense que le servicerégie fonctionnera dans un conteneur OSGI pour instancier un service, mais uniquement dans le même chargeur de classe. Et cela est facilité par l'utilisation de fragments OSGI . Ainsi, tant que la mise en œuvre est dans un fragment qui définit son fragment-host en tant que paquet contenant la classe qui contient le code de recherche ServiceReGistry, le serviceregistry fonctionnera.

C'est pourquoi il fonctionne dans le code XDOCORPORTE que je suis lié. Dans ce cas, le code du serviceLoader est appelé à partir d'une classe abstraite dans fr.opensagres.xdocort.core (un paquet), qui est prolongé par Classe de béton dans fr.opensagres.xdocport.document (donc l'appel du serviceReReRy est dans fr.opensagres.xdocport.xdocort.document). La mise en œuvre du service est dans fr.opensagres.xdocort.document.docx . Un fragment dont a défini son fr.opensagres.xdocport.xdocport.document .

so fr.opensagres.xdocport.document et fr.opensagres.xdocport.document.docx Utilisez le même chargeur de classe ... donc ça marche!

Answer 2

Out de la boîte, Osgi ne prend pas en charge cela, vous devez modifier un peu votre code. Mais il y a des outils autour comme Aries SPI Fly and Pax-Swissbox qui prend en chargetoi En utilisant ces "services" SPI

Answer 3

Non, ça ne le fait pas.Je pense que cela ne découvrira que des services dans le chargeur de classe système, de sorte que c'est assez inutile pour les paquets.

Il pourrait y avoir une solution de contournement, cette POST est joliutile, bien que je doute si cela est d'une utilisation à votre problème.

aussi OSGI 5 aura également un support pour celui-ci («médiateur de chargeur de service»).La mise en œuvre de référence est SPI Fly of Apache Aries

Answer 4

dans xdocreport, nous voulions avoir une API API modulaire à gérer:

• Tout type de document (DOCX, ODT, PPTX ...). Et vous pouvez implémenter votre propre type de document si vous le souhaitez et l'enregistrer via Javax.ImageIO.SPI.ServiceReGyRy.
• Tout type de moteur de modèle (Freemarker, Velocity ...). Et vous pouvez implémenter votre propre modèle si vous le souhaitez et l'enregistrer via Javax.ImageIO.Spi.ServiceReGyRy.
• Tout type de convertisseur (convertisseur DOCX-> PDF avec POI + ITEXT, DOCX-> XHTML Convertisseur avec POI, ODT-> Convertisseur PDF avec ODFDOM + ITEXT, ODT-> Convertisseur XHTML avec ODFDOM ...). Et vous pouvez implémenter votre propre convertisseur si vous le souhaitez et l'enregistrer via javax.imageio.spi.serviceegistry (ex: implémentez DOCX-> PDF Converter avec DOCX4J + FOP, DOCX-> PDF Converter avec JODCONVERTER, etc.).

  Comme vous avez compris, javax.imageo.spi.serviceRégistry fonctionne sur le contexte OSGI car Nous utilisons le fragment OSGI (partage le même chargeur de classe) et non à Osgi Bundle. Nous avons fait ce choix pour gérer le contexte non OSGI et OSGI avec le même code.

  Nous avons décidé d'utiliser le fragment OSGI et non à Osgi Bundle parce que:

  1. Si nous utilisons Osgi Bundle, nous devons développer un activateur OSGI pour enregistrer notre découverte (dans ce contexte Bundle, javax.imageio.spi.serviceRegy ne fonctionne pas).
  2. Si nous utilisons Bundle Osgi, vous devez configurer le niveau de démarrage pour chaque paquets qui enregistre la découverte.

     Le seul problème à utiliser le fragment OSGI est que vous ne pouvez pas utiliser dans votre conteneur OSGI plusieurs version du modèle XDOCORTEM, convertisseur, document. Mais est-ce une bonne fonctionnalité pour XDOCREPORT?

     Vous ne devez pas que JAVAX.IMAGAGEIO.SPI.SERVICEREGRY fonctionne avec JDK5 (et JDK6). JDK6 fournit Java.Util.ServiceLoader qui est de nouveaux CLAS aux services de RegSiter comme javax.imageio.spi.serviceegistry.

     Dans XdocRePort, nous souhaitons prendre en charge JDK5 + JDK6. Xdocort 0.9.8 Utilisé uniquement JAVAX.IMAGIO.SPI.SERVICERÉGIE . Mais il semble que Google App Boîte interdit l'utilisation de cette classe (voir notre problème 132 ). J'ai donc développé pour xdocreport 1.0.0 jdkserviceLoader à gérer avec la réflexion Java java.util.serviceloader et javax.imageo.spi .ServiceeRégie pour JDK5 et JDK6.

     Cordialement Angelo