felix - osgi liferay
¿Los paquetes OSGI separados para la API y la implementación son prácticas comunes? (3)
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 solo paquete 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 PackageAdmin # refreshPackages (esto es automático cuando se usa fileinstall).
He arreglado esto creando un paquete de api separado.
¿Es esta la mejor manera de lograr esto?
¿Alguna vez tendría un paquete que exporta su api e incluye la implementación en el mismo paquete? Por lo que puedo ver, cualquier paquete de donación exportaría todas sus clases o ninguna clase. ¿Qué me estoy perdiendo?
A menos que exista un requisito importante para poder reemplazar la implementación en tiempo de ejecución, sin reiniciar los paquetes de clientes, personalmente recomendaría mantener el vínculo de dependencia explícito entre la API y la implementación (ya sea mediante la inclusión de clases impl en el paquete de API, o al tener el paquete de API Importar paquetes de implementación desde el 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 con API, también incluyen asegurar un comportamiento de tiempo de ejecución constante y predecible, así como la compatibilidad con el ecosistema de implementación, y todos ellos requieren la administración de las dependencias de implementación.
Definitivamente, es una práctica recomendada separar los paquetes de API de sus implementaciones en OSGi. Si lo hace, entonces cualquier paquete que use la API solo necesita importar clases del paquete de la API, lo que puede permitirle cambiar las 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 provista por la API. Esto permite que los paquetes de clientes utilicen el servicio sin hacer referencia al paquete de implementación.
En Apache Sling hacemos ambas cosas: las API principales están en sus propios paquetes, pero para cosas más pequeñas como extensiones o componentes opcionales, a menudo proporcionamos la implementación predeterminada en el mismo paquete que la API.
En el último caso, aún puede permitir que los servicios predeterminados sean reemplazables, por ejemplo, utilizando valores de clasificación de servicios cuando desee anularlos.
Un paquete no tiene que exportar todas sus clases, nuestros paquetes que incluyen servicios predeterminados exportan solo los paquetes API (y las implementaciones predeterminadas están en paquetes diferentes, obviamente).