OSGi: ¿Cuán madura es esta tecnología?

Question

Tengo un requisito en el que tengo que compartir algunos recursos web (jsp, html, js, images, css etc.) a través de diferentes aplicaciones basadas SpringStruts 2. Y parece que OSGi se puede utilizar para lograr esto?

• ¿Puede alguien dar algunos consejos sobre cómo lograr esto con OSGi?
• Y en segundo lugar, quiero saber es OSGi lo suficientemente maduro para ser utilizado en aplicaciones de producción?

¡Gracias de antemano!

EDIT: Fui a través this puesto y parece que la gente son capaces de compartir un paquete web a través de aplicaciones web. La única diferencia es que lo hicieron con Spring MVC. Quiero saber si esto también se puede lograr con las aplicaciones de Struts2.

EDIT 2: Soy básicamente poco claro acerca de lo siguiente:

• ¿El 'compartible-paquete' (que contiene los recursos de Internet para compartir) sea un .war empaquetado. En caso afirmativo, ¿desde dónde se formará el contexto web final ya que este paquete se va a compartir nuevamente con la aplicación principal 'web'? Espero que el contexto web final se forme a partir de la fusión de la aplicación web "compartible" y la "principal". ¿Sucederá automáticamente? ¿Algunas ideas?

Answer 1

Si bien OSGI podría ser una solución, podría ser un poco exagerado (y, como señaló Bozho, necesitará un contenedor compatible con OSGI).Tal vez echar un vistazo a How to share resources across projects in Maven para otras opciones:

• cortar y pegar.
• Uso Assembly y plugins Dependency
• Use la maven-remote-resources-plugin

En este blog voy a mostrar cómo hacer la segunda opción ya que en mi opinión, es es actualmente el más estable y flexible. En el futuro, probaré el maven-remote-resources-plugin y escribo un tutorial.

EDITAR: Para responder un comentario del OP. Sí, la idea es crear un conjunto de los recursos web que se pueden compartir y usar el complemento maven-dependency-plugin para extraer y descomprimir el ensamblado en los proyectos "recursos-consumidores". Todo esto se explica y detalla en la entrada del blog mencionada anteriormente. Avíseme si algo no está claro en eso.

Answer 2

OSGi se utiliza en Eclipse, GlassFish, ServiceMix (y otros, también), que son productos de software maduros. Sin embargo, son de naturaleza muy específica, y mi opinión personal es que OSGi no es muy adecuado para los proyectos de tipo común. Por lo que sé (alguien me corrige, si hay noticias en esta área), si desea usar OSGi con aplicaciones web, necesitará un contenedor de servlet incluido en OSGi. Además, poner recursos (html, js, images) en paquetes OSGi puede ser problemático.

Answer 3

OSGi es una tecnología bastante madura: así es como se estructuran todos los complementos de Eclipse. Sin embargo, la tecnología todavía tiene que ganar tracción en el espacio de la aplicación web porque hay muy pocos contenedores de servlets que lo admitan.

Si desea leer sobre él, debe consultar Modular Java de Craig Wells, ya que ofrece una base bastante buena sobre OSGi en relación con Spring Framework.

Con respecto a compartir recursos, es posible que desee examinar un paquete EAR. Lo he usado con éxito para implementar varios archivos WAR con un conjunto común de recursos (por ejemplo, una versión comprimida de Dojo).

Por ejemplo, una oreja puede verse como:

ear-file/proj1 
ear-file/proj2 
ear-file/config 
ear-file/lib 
ear-file/resources 
ear-file/META-INF 
ear-file/APP-INF 

También puede leer sobre el hilo .war vs .ear file desde un puesto de stackoverflow anterior.

Answer 4

no estoy demasiado familiarizado con puntales (o Spring MVC, para el caso), pero lo podría hacer en el SpringSource dm Server. Se basa en Equinox, el contenedor OSGi utilizado por Eclipse, y un Apache Tomcat bundled (así como las cosas del framework Spring).

Con el servidor SpringSource, cada archivo de la guerra se despliega más o menos tradicional, pero pueden acceder a recursos (clases, servicios, etc.) a través de los mecanismos normales de OSGi. Esos mecanismos se basan en los cargadores de clases del paquete OSGi, lo que puede ser problemático para compartir recursos de archivos como jsps, html, css, etc. Podría funcionar si tuviera algo similar al DefaultServlet que procesara cosas del cargador de clases en lugar del sistema de archivos. (O, diablos, podría estar haciendo esto más complicado de lo que necesito).

Por otro lado, podría implementar todo como aplicaciones web independientes y unirlo todo en el extremo del cliente.

La primera respuesta a la pregunta the modular web apps parece realmente interesante, aunque no directamente aplicable al servidor SpringSource, ya que no proporciona el OSGi HttpService. Creo que el reciente trabajo de especificación empresarial de OSGi 4.2 se dirige también hacia el enfoque desplegar-war-files-as-OSGi-bundles del servidor SpringSource.

En respuesta a su EDIT 2 pregunta , si he entendido bien, el "contexto web" en ese answer sería construido de forma dinámica mediante el HttpService, que es una interfaz que proporciona métodos para

1. registrar servlets bajo URLs y

2. registrar recursos (archivos, etc.) en las URL.

Dado que esas operaciones se manejan dinámicamente, no es necesario que haya nada que combine explícitamente bits de contexto web.