Cómo modularizar un JSF/Facelets/Primavera de la aplicación con OSGi?

Question

Estoy trabajando con grandes JSF/Facelets las aplicaciones que utilizan la Primavera de DI/bean de gestión.Mis aplicaciones tienen una estructura modular y actualmente estoy en busca de enfoques para estandarizar la modularización.

Mi objetivo es componer una aplicación web a partir de una serie de módulos (posiblemente dependiendo de cada uno de los otros).Cada módulo puede contener lo siguiente:

• Clases;
• Los recursos estáticos (imágenes, CSS, scripts);
• Facelet plantillas;
• Managed beans - la Primavera de los contextos de aplicación, junto con la solicitud, de sesión y de ámbito de aplicación de las habas (alternativa es JSF managed beans);
• Servlet API cosas - servlets, los filtros, los oyentes (esto es opcional).

Lo que me gustaría evitar que (casi en todos los costos) es la necesidad de copiar o extraer el módulo de recursos (como Facelets plantillas) para la GUERRA o para ampliar la web.xml para el módulo de servlets, filtros, etc.Debe ser suficiente para añadir el módulo (JAR, paquete, artefacto, ...) para la aplicación web (WEB-INF/lib, bundles, plugins, ...) para extender la aplicación web con este módulo.

Actualmente voy a resolver esta tarea con una costumbre de la modularización de la solución que está fuertemente basado en el uso de ruta de clases recursos:

• Los recursos especiales servlet sirve recursos estáticos de la ruta de clases de recursos (Frascos).
• Especial Facelets recurso de resolución permite la carga de Facelet plantillas de ruta de clases de recursos.
• La primavera de las cargas de los contextos de aplicación a través del patrón de classpath*:com/acme/foo/module/applicationContext.xml - este cargas de los contextos de aplicación definido en el módulo de los Frascos.
• Por último, un par de delegar servlets y los filtros delegado de procesamiento de la solicitud a los servlets y los filtros configurados en la Primavera de los contextos de aplicación de los módulos.

Últimos días he leído mucho acerca de OSGi y yo estaba pensando, ¿cómo (y si) yo podría utilizar OSGi como un estándar de la modularización de enfoque.Yo estaba pensando acerca de cómo cada una de las tareas podría ser resuelto con OSGi:

• Los recursos estáticos - OSGi paquetes que desea exportar los recursos estáticos registrar un ResourceLoader instancias con el paquete de contexto.Un central ResourceServlet utiliza estos recursos cargadores para cargar recursos de paquetes.
• Facelet plantillas - similar a la anterior, una central ResourceResolver utiliza los servicios registrados por grupos.
• Managed beans - No tengo idea cómo utilizar una expresión como #{myBean.property} si myBean se define en uno de los paquetes.
• Servlet API cosas - usar algo como WebExtender/Pax Web para registrar servlets, filtros y así sucesivamente.

---

Mis preguntas son:

• Estoy inventando una bicicleta aquí?Hay soluciones estándar para que?He encontrado una mención de Primavera Rodajas, pero no pudo encontrar mucha documentación al respecto.
• ¿Crees que OSGi es la tecnología adecuada para la tarea?
• Es mi boceto de OSGI aplicación más o menos correcta?
• ¿Cómo debería de managed beans (especialmente de solicitud/sesión ámbito de aplicación) se maneja?

Me gustaría ser en general gracias por sus comentarios.

Answer 1

Lo que estás intentando hacer sonidos factible, con un par de salvedades:

La Capa De La Vista: En primer lugar, su capa de la vista suena un poco mullido.Hay otras maneras de modularizar de componentes JSF mediante el uso de componentes personalizados que evitar los dolores de cabeza involucradas con el intento de crear algo tan dramático como enlace administrado frijoles.

Los Módulos De: Segundo, los módulos no parecen muy modular.Su primera viñeta de la lista la hace sonar como si usted está tratando de crear interoperables de aplicaciones web, en lugar de los módulos de por sí.Mi idea de un módulo es que cada componente tiene una bien definida, y más o menos discreta, propósito.Como la forma ex subyace vi.Si usted va por la OSGi ruta, entonces debemos definir modular como este: Modular, por el bien de esta discusión, significa que los componentes son intercambiables en caliente, es decir, que puede ser añadido y se retira sin romper la app.

Dependencias: Estoy un poco preocupado por su descripción de los módulos como "posiblemente dependiendo el uno del otro." Usted probablemente (espero) ya lo sabes, pero sus dependencias debe formar un gráfico acíclico dirigido.Una vez que introduce una dependencia circular, que está pidiendo un mundo de daño en términos de la aplicación eventual de la capacidad de mantenimiento.Una de las mayores debilidades de OSGi es que no evitar circular dependencias, por lo que depende de usted para hacer cumplir esto.De lo contrario, sus dependencias crecerá como kudzu y poco a poco ahogar el resto de su sistema del ecosistema.

Servlets: Olvídense de eso.Usted no puede enlazar de tiempo de ejecución servlets en una aplicación web, no hasta que el Servlet 3.0 especificación es en la producción (como Pascal señaló).Para iniciar una utilidad independiente servlet, tendrás que ponerlo en su propia aplicación.

---

OK, tanto para las advertencias.Vamos a pensar acerca de cómo podría funcionar esto:

Usted ha definido su propio JSF módulo de hacer...¿qué, exactamente?Vamos a darle un definidos, bastante trivial propósito:una pantalla de inicio de sesión.Para crear tu pantalla de inicio de sesión, tarde-se unen mediante OSGi en su aplicación y...entonces, ¿qué?¿Cómo funciona la aplicación de conocer la funcionalidad de inicio de sesión está ahí, si no se ha definido en su .jspx página?¿Cómo funciona la aplicación saber para navegar a algo que no puede saber que está ahí?

Hay maneras de conseguir alrededor de este uso de condicionales incluye y similares (p. ej., <c:if #{loginBean.notEmpty}>), pero, como usted dice, las cosas se ponen un poco peluda cuando el administrado loginBean existe en otro módulo que no han sido introducidos a la aplicación todavía.De hecho, usted obtendrá un servlet excepción, salvo que loginBean existe.Entonces, ¿qué hacemos?

Se define una API en uno de sus módulos. Todos los managed beans que desea compartir entre los módulos debe ser especificado como interfaces en esta capa de API.Y todos sus módulos deben tener implementaciones predeterminadas de cualquiera de estas interfaces que va a utilizar.Y esta API debe ser compartida entre todos los interoperables módulos.A continuación, puede utilizar OSGi y la Primavera para conectar a la especificada frijoles con su aplicación.

Necesito tomar un momento para señalar que esto no es como me gustaría enfocar este problema.No en todos.Dado algo como tan simple como una página de inicio de sesión, o incluso tan complicado como un gráfico de cotizaciones, yo personalmente prefiero crear una personalizada componente JSF.Pero si el requisito es "quiero que mi managed beans ser modular (es decir, hot-swap, etc)," esta es la única manera que conozco de hacer el trabajo.Y ni siquiera estoy completamente seguro de que se trabajo. Este intercambio de correo electrónico sugiere que es un problema que JSF desarrolladores han empezado a trabajar.

Yo, normalmente, considere la posibilidad de managed beans ser parte de la capa de la vista, y, como tal, yo los uso solo para ver la lógica, y delegar todo lo demás a la capa de servicio.Hacer administrado frijoles de enlace es, a mi parecer, la promoción de las mismas fuera de la capa de la vista y en la lógica de negocio.Hay una razón por la que todos los tutoriales están muy enfocados en los servicios de:debido a que la mayoría de las veces que desee considerar lo que se necesitaría para su aplicación a ejecutar "sin cabeza", y lo fácil que sería "piel" su punto de vista si, por ejemplo, quería correr, con toda su funcionalidad, en un teléfono Android.

Pero suena como un montón de lo que estamos trabajando es en sí la lógica de una vista, como por ejemplo, la necesidad de cambiar de una vista diferente de la plantilla.OSGi/Primavera debe ser capaz de ayudarle, pero usted necesitará algo en su aplicación a elegir entre los disponibles implementaciones:bastante más de lo OSGi del Servicio de Registro fue construido a hacer.

Que las hojas de los recursos estáticos.Usted puede modularizar de estos, pero recuerde que usted necesitará para definir una interfaz para recuperar estos recursos, y deberá proporcionar una implementación predeterminada de modo que su aplicación no se ahogue si están ausentes.Si i18n es una consideración, esta podría ser una buena manera de ir.Si usted quiere ser realmente aventurero, entonces usted podría empujar a la estática de los recursos en JNDI.Que haría completamente intercambiables en caliente, y para ahorrarle el dolor de tratar de resolver la aplicación que debe utilizar mediante programación, pero hay algunas desventajas:cualquier error de búsqueda hará que su aplicación para lanzar una NamingException.Y que es una exageración.JNDI se utiliza normalmente en aplicaciones web para la configuración de aplicación.

Como para el resto de tus preguntas:

Estoy inventando una bicicleta aquí?Hay soluciones estándar para que?

Son, un poco.He visto aplicaciones que hacen esto tipo de la cosa, pero parece que han caído en un bastante conjunto único de requisitos.

¿Crees que OSGi es la tecnología adecuada para la tarea?

Si usted necesita los módulos intercambiables en caliente, a continuación, sus opciones son OSGi y el peso ligero ServiceLocator de la interfaz.

Es mi boceto de OSGI aplicación más o menos correcta?

Puedo decir sin saber más sobre el lugar donde su componente límites.Por el momento, parece que usted puede empujar OSGi para hacer más de lo que es capaz de hacer.

Pero no tome mi palabra para ella. Yo encuentra otros material de lectura en estos lugares.

Y ya de preguntar acerca de la Primavera Rodajas, esto debería ser suficiente para empezar.Usted necesitará un cliente Git, y parece que va a ser la formación de sí mismo en la app mirando a través del código fuente.Y es muy temprano prototipo de código.

Answer 2

Me enfrento a los mismos problemas en mi proyecto actual. En mi opinión, OSGI es la mejor y más limpia solución en términos de estándares y soporte futuro, pero actualmente puede tener algunos problemas si intenta usarlo en una aplicación web:

1. Todavía no hay una solución bien integrada entre un contenedor web y la plataforma OSGI.
2. OSGI puede ser demasiado para una aplicación web de compilación personalizada que solo busca una arquitectura modularizada simple. Consideraría OSGI si mi proyecto necesita admitir extensiones de terceros que no están 100% bajo nuestro control, si el proyecto necesita redistribuiciones en caliente, reglas de acceso estrictas entre complementos, etc.

Una solución personalizada basada en cargadores de clase y filtros de recursos me parece muy apropiada. Como ejemplo, puedes estudiar el Código fuente de Hudson o proyecto Java Plug-In Framework (JPF) (http://jpf.sourceforge.net/).

Como sobre extender el Web.xml, podemos tener suerte con la especificación Servlet 3.0 (http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3.html# Contabilidad y extensibilidad).

Answer 3

El "fragmento de descriptor de implementación de módulo web" (también conocido como web-fragment.xml) introducido por el Especificación de servlet 3.0 Sería bueno aquí. La especificación lo define como:

Un fragmento web es una partición lógica de la aplicación web de tal manera que los marcos que se utilizan dentro de la aplicación web pueden definir todos los artefactos sin pedirle a DevLopers que edite o agregue información en Web.xml.

Sin embargo, Java EE 6 no es una opción para ti en este momento. Aún así, sería la solución estandarizada.

Answer 4

Enterprise OSGI es un dominio bastante nuevo, así que no piense que obtendrá una solución que satisfaga directamente sus necesidades. Dicho esto, una de las cosas que encontré que faltaban en Equinox (el motor OSGI detrás de Eclipse y, por lo tanto, una con la base de usuarios más grande) es un servicio de configuración / DI consistente. En mi proyecto recientemente tuvimos algunas necesidades similares y terminamos construyendo un servicio OSGI de configuración simple.

Uno de los problemas que serán inherentes a las aplicaciones modulares estaría alrededor de DI, ya que la visibilidad del módulo podría evitar el acceso a la clase en algunos casos. Nos arreglamos esto usando una política de Buddy registrada, que no es demasiado ideal pero funciona.

Además de la configuración, puede echar un vistazo al libro de equinox recientemente lanzado para obtener orientación sobre el uso de OSGI como base para crear aplicaciones modulares. Los ejemplos pueden ser específicos para el equinoccio, pero los principios funcionarían con cualquier marco de OSGI. Enlace - http://equinoxosgi.org/

Answer 5

Debe investigar el servidor Spring DM (se está haciendo la transición para eclipse de Virgo, pero eso aún no se ha lanzado). Hay muchas cosas buenas en la reciente especificación de OSGI Enterprise que también acaba de lanzarse.

Algunos de los tutoriales de Spring DM ayudarán, me imagino. Pero sí, es posible tener recursos y clases cargados desde fuera del paquete web utilizando modularidad estándar. En eso, es un buen ajuste.

En cuanto al contexto de la sesión, se maneja como cabría esperar en una sesión. Sin embargo, puede tener problemas para compartir esa sesión entre los paquetes web en la medida en que no está seguro si es posible.

También puede buscar tener un solo paquete web y luego usar, por ejemplo, el Registro de Extensión Eclipse para extender las capacidades de su aplicación web.