2010-01-25 19 views
7

Después de pedir ayuda para gestionar dependencias en diferentes versiones de las mismas bibliotecas en Java, se sugirió que debería echar un vistazo a las implementaciones OSGI. Al estar bajo una presión de fecha límite, realmente podría usar alguna ayuda que me salvaría de cavar a través de interminables documentos OSGI. Tengo una aplicación que funciona, que va a utilizar un nuevo marco. El marco utiliza diferentes versiones de jar que ya estoy usando, por lo que quiero empaquetar el nuevo marco como un paquete OSGI. ¿Puedo dejar mi aplicación tal como está y utilizar el paquete OSGI solo como un contenedor dentro de JVM? Esto significaría que usaría el paquete OSGI solo para aislar un conjunto de clases del resto de la JVM para evitar conflictos entre diferentes versiones de clases. en otras palabras, quiero usar OSGI sin llevar todo mi código a una configuración basada en OSGI.Cómo empaquetar y consumir una biblioteca Java existente con OSGI

Saludos cordiales Seref

Respuesta

3

que no tienen una respuesta completa para usted aquí, sólo quería contrarrestar lo deterb dicho:

En primer lugar, usted tiene que tener toda su aplicación en el marco de OSGi.

Eso no es verdad. Otro enfoque sería insertar un contenedor OSGi en una aplicación host.

La parte difícil aquí es la interacción entre el interior de OSGi y el exterior, porque el código reside en cargadores de clases separados.

Puede hacer que las clases de su host sean visibles para la parte OSGi utilizando el classpath del sistema OSGi. Al revés, es más difícil.

Una forma de que el código de host interactúe con los paquetes es una interfaz que es visible tanto para la aplicación host como para el paquete, es decir, parte del host. Otra forma sería usar la reflexión.

Si tiene una separación clara entre el host y OSGi, por ejemplo, un sistema de complementos, esto podría funcionar bastante bien.

El estar bajo una presión de tiempo

Eso podría ser un problema. Hay mucho que aprender con OSGi, y dado que está a punto de llegar a la corriente principal, todavía hay una falta de conocimiento de la comunidad, soporte de herramientas, compatibilidad de bibliotecas, etc.

La pregunta más importante que debe formular en ese momento es: ¿Realmente necesito administrar versiones diferentes de dependencias en tiempo de ejecución? Si no, es decir, puede resolver las cosas en el momento de la implementación (por ejemplo, mediante la configuración), entonces puede haber una solución más simple para usted.

+0

Gracias Thilo (y deterb), esta es la situación: mi software está utilizando una biblioteca particular, que tiene dependencias con x.v1.jar. Ahora tengo que agregar otra biblioteca a mi proyecto, que tiene dependencias con x.v1.1.jar En este caso, incluso si administro cosas en tiempo de compilación, en tiempo de ejecución, tendrá que haber dos jarras, que contengan clases con los mismos nombres, y ya sea la primera biblioteca que estoy usando o la segunda puede terminar accediendo a la versión incorrecta de una clase, o no puede llegar a una clase, etc. El desorden no es difícil de imaginar. – mahonya

+0

Ahora, si pudiera crear una especie de recinto de seguridad dentro de JVM, por ejemplo, al poner toda la nueva biblioteca en un paquete, me estaría deshaciendo de mi problema. En este caso, estaría usando algún tipo de mecanismo para cargar tipos de la biblioteca empaquetada (mecánica OSGI). Por ejemplo, si puedo usar los nombres de reflejo y tipo para recuperar instancias de tipos contenidos en OSGI, ¿usarían esos tipos el cargador de clases del contenedor OSGI? De ser así, cargarían tipos de x.v1.1.jar y esta podría ser una solución en mi caso. Consideraría cambiar todo a OSGI gradualmente, si puedo manejar este pequeño pero crítico caso de uso. – mahonya

+0

@serefakin: Sí, podría poner x.v1.1.jar en OSGi, pero también debe colocar la biblioteca que depende de él (porque debe evitar que vea x.v1.jar). Y eso hace que sea difícil usar la biblioteca desde un código fuera de OSGi (a menos que tenga una interfaz que también pueda vivir fuera). – Thilo

0

En primer lugar, usted tiene que tener toda su aplicación en el marco de OSGi. Sin embargo, no creo que sea difícil configurarlo para que solo tenga que trabajar con unos pocos paquetes (quizás solo dos, dependiendo de su configuración.

El camino con menos problemas que puedo ver sería sea ​​tomar el marco y "ajustarlo" y todas sus dependencias en un paquete único. Hacer que los paquetes para las dependencias sean privados. Para su proyecto principal, haga lo mismo.

La otra ruta sería empaquetar todo el bibliotecas por separado utilizando los comandos adecuados wrap. Esto tiene muchos más problemas potenciales si no está interesado en completar OSGi.

Dependiendo de la configuración de su compilación, me gustaría comenzar echando un vistazo a la maven-bundle-plugin y/o Bnd. El complemento maven-dependency lo hace bastante fácil, ya que todo lo que tiene que hacer es decirle qué ID de artefactos incorporar y lo hará. Deberá asegurarse de especificar todos los paquetes jar incrustados como paquetes privados.

Esto debería funcionar, a menos que el framework esté haciendo la carga de clase/AOP, lo que dificultaría significativamente a OSGify.

Por último, si usted está interesado en una solución rápida no osgi, construir el marco con la maven-shade-plugin y simplemente cambiar el nombre de todos los paquetes para las bibliotecas en conflicto. Esto probablemente sería el más fácil, ya que solo volvería a empaquetar el marco con las bibliotecas sombreadas una vez y luego lo usaría como su dependencia.

Cuestiones relacionadas