¿Hay paquetes OSGI separados para api y práctica común de implementación?

Question

Tengo una clase con dependencias que deseo implementar en caliente sin reiniciar las dependencias. La clase tiene una interfaz, pero solo hay una implementación concreta.

Inicialmente, creé un paquete único con la interfaz exportada y registré la implementación utilizando el activador y las clases de implementación que no se exportaron. Sin embargo, si actualizo el paquete, los paquetes que usan el servicio registrado se reinician después de la actualización cuando se llama a PackageAdmin # refreshPackages (esto es automático cuando se usa la instalación de archivos).

He solucionado esto creando un paquete api por separado.

¿Es esta la mejor manera de lograrlo?

¿Alguna vez tendrá un paquete que exporte su API e incluya la implementación en el mismo paquete? Por lo que puedo ver, cualquier conjunto de datos podría exportar todas sus clases o no tener clases. ¿Qué me estoy perdiendo?

Answer 1

Definitivamente es una mejor práctica separar paquetes de API de sus implementaciones en OSGi. Si hace esto, cualquier paquete que use la API solo necesita importar clases desde el paquete API, lo que puede permitirle cambiar implementaciones en tiempo de ejecución sin reiniciar sus paquetes dependientes.

Idealmente, su paquete de implementación implementaría la interfaz y exportaría la implementación como un servicio en la interfaz proporcionada por la API. Esto permite que los paquetes de clientes utilicen el servicio sin hacer referencia al paquete de implementación.

Answer 2

En Apache Sling hacemos ambas cosas: las principales API están en sus propios paquetes, pero para cosas más pequeñas como extensiones o componentes opcionales a menudo ofrecemos la implementación predeterminada en el mismo paquete que la API.

En este último caso, aún puede permitir que esos servicios predeterminados sean reemplazables, por ejemplo, utilizando valores de rangos de servicio cuando desee anularlos.

Un paquete no tiene que exportar todas sus clases, nuestros paquetes que incluyen servicios predeterminados solo exportan los paquetes API (y las implementaciones predeterminadas están en diferentes paquetes, obviamente).

Answer 3

A menos que sea un requisito difícil poder reemplazar la implementación en tiempo de ejecución, sin reiniciar paquetes de clientes, yo personalmente recomendaría mantener el vínculo de dependencia explícito entre la API y la implementación (incluyendo clases impl en el paquete API o tener paquetes de implementación de paquete de API del paquete impl.).

El pb con los patrones sugeridos anteriormente es que rompen la cadena de dependencia. Los beneficios de la administración de dependencias van más allá de la simple compatibilidad de API, también incluyen garantizar un comportamiento de tiempo de ejecución predecible y uniforme, así como la compatibilidad con el ecosistema de implementación, y todos requieren la administración de las dependencias de implementación.