¿Funciona javax.imageio.spi.ServiceRegistry en un contenedor OSGi?

Question

¿Alguien puede decirme definitivamente si un paquete osgi que contiene código que llama

javax.imageio.spi.ServiceRegistry

para encontrar un servicio (en META-INF\servicio) encontrará ese servicio, si la implementación de ese servicio está en otro paquete.

No encuentro ninguna documentación que sea específica sobre esto.Estoy usando el contenedor felix osgi.Cualquier sugerencia será recibida con gratitud.

Sospecho que funciona y mi problema radica en otra parte, ya que noto que en el paquete xdocreport osgi fr.opensagres.xdocreport.core, ServiceRegistry se acostumbra aquí ¿Pero tal vez no sea compatible con todos los contenedores OSGI?

Answer 1

Hola, gracias a todos por sus respuestas.Creo que ServiceRegistry funcionará en un contenedor osgi para crear una instancia de un servicio, pero solo dentro del mismo cargador de clases.Y eso se ve facilitado por el uso de fragmentos de osgi.Entonces, siempre que el implementador esté en un fragmento que defina su Fragment-host como el paquete que contiene la clase que tiene el código de búsqueda de ServiceRegistry, ServiceRegistry funcionará.

Es por eso que funciona en el código xdocreport al que me vinculé.En este caso, el código ServiceLoader se llama desde una clase abstracta en es.opensagres.xdocreport.core (un paquete), que se extiende por clase concreta en es.opensagres.xdocreport.document (por lo que la llamada a ServiceRegistry está en fr.opensagres.xdocreport.document).La implementación del Servicio está en es.opensagres.xdocreport.document.docx.un fragmento que ha definido su frament-host como fr.opensagres.xdocreport.document.

Entonces fr.opensagres.xdocreport.document y fr.opensagres.xdocreport.document.docx usan el mismo cargador de clases... ¡así que funciona!

Answer 2

OSGi no es compatible con esto, por lo que necesitarás modificar un poco tu código.Pero existen herramientas como Aries SPI Fly y Pax-Swissbox que te apoyan en el uso de estos "servicios" de SPI

Answer 3

No, no es así.Creo que sólo descubrirá servicios en el cargador de clases del sistema, por lo que es bastante inútil para los paquetes.

Podría haber una solución, esta correo es bastante útil, aunque dudo que sea de alguna utilidad para tu problema.

Además, OSGi 5 tendrá soporte para ello ('Service Loader Mediator').La implementación de referencia es SPI vuela desde Apache Aries

Answer 4

En XDocReport queríamos tener un informes API modulares administrar :

• cualquier tipo de documento (docx, odt, pptx...).Y puede implementar su propio tipo de documento si lo desea y registrarlo a través de javax.imageio.spi.ServiceRegistry.
• cualquier tipo de motor de plantillas (Freemarker, speed...).Y puede implementar su propio tipo de plantilla si lo desea y registrarla a través de javax.imageio.spi.ServiceRegistry.
• cualquier tipo de convertidor (convertidor docx->pdf con POI+iText, conversor docx->xhtml con POI, conversor odt->pdf con ODFDOM+iText, conversor odt->xhtml con ODFDOM...).Y puede implementar su propio convertidor si lo desea y registrarlo a través de javax.imageio.spi.ServiceRegistry (por ejemplo:implementar el convertidor docx->pdf con docx4j+FOP, el convertidor docx->pdf con JODConverter, etc.).

Como has entendido, javax.imageio.spi.ServiceRegistry funciona en el contexto OSGi porque Usamos fragmento OSGi (comparte el mismo cargador de clases) y no el paquete OSGi.Hemos tomado esta decisión para administrar el contexto OSGi y no OSGi con el mismo código.

Hemos decidido utilizar el fragmento OSGi y no el paquete OSGi porque:

1. Si usamos el paquete OSGi, necesitamos desarrollar un activador OSGi para registrar nuestro descubrimiento (en este paquete de contexto, javax.imageio.spi.ServiceRegistry no funciona).
2. Si utilizamos el paquete OSGi, debe configurar el nivel de inicio para cada paquete que registre el descubrimiento.

La única desventaja de usar un fragmento OSGi es que no puede usar en su contenedor OSGi varias versiones de la plantilla, el convertidor o el documento de XDocReport.¿Pero es una buena característica para XDocReport?

no debes eso javax.imageio.spi.ServiceRegistry Funciona con JDK5 (y JDK6).JDK6 proporciona java.util.ServiceLoader que es una nueva clase para registrar servicios como javax.imageio.spi.ServiceRegistry.

en XDocReport deseamos soportar JDK5+JDK6.XDocReport 0.9.8 usado únicamente javax.imageio.spi.ServiceRegistry.Pero parece que Google App Engine prohíbe el uso de esta clase (ver nuestro número 132).Así que desarrollé para XDocReport 1.0.0 Cargador de servicios JDK para gestionar con la reflexión de Java ambos java.util.ServiceLoader y javax.imageio.spi.ServiceRegistry para JDK5 y JDK6.

Saludos Ángel