Extender aplicaciones web Java con plugins

Question

Tengo esta aplicación web que se ha convertido en un lío inmanejable.

Quiero dividirlo en un marco común " " " parte (que aún incluye material web como páginas e imágenes) y varios módulos que agregan funciones y pantallas adicionales. Quiero que esta refactorización también sea útil como sistema de complementos para extensiones de terceros.

Todos los módulos deben ser una unidad de implementación separada, idealmente un archivo de guerra o un archivo jar.

Intenté crear varios archivos war normales, pero Tomcat mantiene (según la especificación del servlet) estos archivos war completamente separados entre sí, por lo que no pueden compartir sus clases, por ejemplo.

Necesito complementos para poder ver el " main " classpath.

Necesito la aplicación principal para tener cierto control sobre los complementos, como poder enumerarlos y establecer su configuración.

Me gustaría mantener una separación completa entre los complementos (a menos que especifiquen las dependencias) y cualquier otra aplicación web no relacionada que pueda estar ejecutándose en el mismo Tomcat.

Me gustaría que estuvieran enraizados en la sección " main " prefijo de la URL de la aplicación, pero eso no es necesario.

Me gustaría usar Tomcat (los grandes cambios arquitectónicos deben coordinarse con demasiada gente), pero también para escuchar sobre una solución limpia en el mundo de EJB o OSGi, si los hay.

Answer 1

He estado jugando con la idea de usar OSGi para resolver el mismo problema que estás describiendo. En particular, estoy considerando el uso de Spring Dynamic Modules .

Answer 2

Eche un vistazo a los portlets de Java - http://developers.sun.com / portalserver / reference / techart / jsr168 / - en pocas palabras, una especificación que permite la interoperabilidad entre las aplicaciones web j2ee autocontenidas

Editar Olvidé mencionar que los portlets son bastante independientes del marco, por lo que puede usar Spring para la aplicación principal, y los desarrolladores individuales pueden usar lo que quieran en sus portlets.

Answer 3

¿Ha considerado usar maven para separar sus proyectos y luego hacer que resuelva las dependencias entre los WAR y los JAR? Terminarás con la duplicación de bibliotecas entre WAR, pero solo cuando sea necesario (y esto no debería ser un problema a menos que te sumerjas en una diversión funky con el cargador de clases).

Tomcat también le permite configurar aplicaciones de contexto cruzado si necesita pasar de un WAR a otro de una manera relativamente transparente ...

Si desea mantener las cosas bajo la misma aplicación web única (por ejemplo, ROOT), podría crear una aplicación web proxy que se reenvíe a la otra aplicación web relevante detrás del escenario para que el usuario la haga relativamente transparente.

Answer 4

Su problema principal se centrará en los activos físicos y estáticos del sistema; el resto son simples, efectivamente, tarros.

Los WAR están separados, en Tomcat, con cargadores de clases separados, pero también están separados a nivel de sesión (cada WAR es una aplicación web individual y tiene su propio estado de sesión).

En Glassfish, si los WAR estuvieran agrupados en un EAR, compartirían cargadores de clases (GF usa un espacio de cargador de clase plano en los EAR), pero aún tendrían un estado de sesión separado.

Además, no estoy seguro de que puedas hacer un " reenviar " a otro WAR en el servidor. El problema es que los reenvíos utilizan una URL relativa a la raíz de la aplicación web, y cada aplicación web tiene su propia raíz, por lo que simplemente no se puede acceder desde aquí " ;. Puede redirigir, pero eso no es lo mismo que un reenvío.

Por lo tanto, estas características de la aplicación web conspiran para que usted intente implementarlas de manera homogénea dentro del contenedor.

Más bien, creo que la sugerencia es crear un " ensamblador " utilidad que toma sus módulos individuales y " combina " En una sola aplicación web. Puede combinar su web.xml, su contenido, normalizar los archivos y clases, etc.

Los WAR son una característica y un error en el mundo Java. Los amo porque realmente hacen desplegar aplicaciones compiladas " Arrastrar y soltar " en términos de instalación, y esa característica se usa mucho más de lo que te encuentras. Pero siento tu dolor. Tenemos un " core " marco que compartimos en todas las aplicaciones, y básicamente tenemos que fusionarlo continuamente para mantenerlo. Lo hemos escrito, pero sigue siendo un poco molesto.

Answer 5

" Además, no estoy seguro de que puedas hacer un " reenviar " a otro WAR en el servidor. El problema es que los reenvíos utilizan una URL relativa a la raíz de la aplicación web, y cada aplicación web tiene su propia raíz, por lo que simplemente no se puede acceder desde aquí " ;. Puede redireccionar, pero eso no es lo mismo que un reenvío. & Quot;

Puedes reenviar a otro WAR siempre que ese WAR permita que alguien lo haga.

Glassfish y múltiples WARs de un EAR: eso tiene sentido.

Si coloca las clases PRINCIPALES en la CLASSPATH compartida de tomcat, puede poner sus PLUGIN individuales en archivos WAR separados.

La aplicación Principal también puede ser parte del servlet TOMCAT que usted define en server.xml. Este puede ser el MASTER SERVLET y todos los demás WAR pueden ser controlados por este servlet maestro.

¿Eso tiene sentido?

BR,
~ A

Answer 6

Dependiendo de la complejidad de la funcionalidad del complemento, también estaría considerando un servicio web, por ejemplo implementado con Axis.

Su aplicación principal se configura con la URL de la aplicación web (complemento) que proporciona el servicio.

La ventaja, tal como la veo, es doble:

• Obtienes una API agradable, limpia y debugable entre las dos guerras, a saber, la Mensajes de jabón / XML
• Puede actualizar un solo complemento sin tener que realizar una prueba de regresión aplicación completa

Las desventajas son que debes configurar algunos proyectos de Axis y que debes tener algunos tipo de configuración de plugin. Además es posible que tengas que limitar el acceso a tus servicios web. aplicaciones, por lo que podría ser necesario un poco de configuración.

Si los complementos funcionan en la misma base de datos, asegúrate de limitar el tiempo de caché o de configurar una guerra capa de almacenamiento en caché.

Answer 7

También he estado intentando desarrollar un marco común o abstracto donde pueda agregar complementos (o módulos) en tiempo de ejecución y mejorar la aplicación web existente.

Ahora, como usted dijo, prefería la forma de hacerlo usando el archivo WAR o JAR. El problema con el archivo WAR es que no se puede implementar como complemento a la aplicación existente. Tomcat lo implementará como un contexto web separado. No deseable.

Otra opción es crear un archivo JAR y escribir un código personalizado para copiar ese archivo JAR en la carpeta WEB-INF / lib y cargar las clases en el cargador de clases existente. El problema es cómo implementar archivos no Java como JSP o archivos de configuración. Para eso, hay dos soluciones, a. Use plantillas de velocidad en lugar de JSP (b.) Escriba algún código personalizado para leer JSP desde classpath en lugar de la ruta de contexto.

Los módulos OSGI o Spring Dynamic son agradables, pero en este momento, me parecen demasiado complejos. Lo veré de nuevo, si me da la sensación.

Estoy buscando una API simple, que pueda encargarse del ciclo de vida del plugin y aún pueda usar JSP en mi archivo JAR empaquetado.

Puede ser, puede usar un jar el complemento en el momento del despliegue y copiar los archivos a los directorios correctos.

Answer 8

En realidad, no hay nada mejor que OSGI si está pensando en dividir la aplicación en módulos separados. Echa un vistazo al ejemplo de Greenpages. Puede crear un módulo principal (núcleo) en el que incluya los archivos jar que necesita su aplicación.

Si sabe algo sobre la programación de componentes, pronto descubrirá que los módulos OSGI se comportan como interfaces, donde debe exponer lo que usará en otros módulos. Es bastante simple una vez que entiendes. De todos modos, también puede ser muy doloroso cuando aprendes a usar OSGI. Tuvimos problemas al usar JSON, ya que una versión de Jackson que agregamos como jar al módulo, fue anulada por otro jar que estaba contenido en los módulos principales de Spring. Siempre tiene que volver a verificar qué versión de jar se carga para sus necesidades.

Desafortunadamente, incluso el enfoque OSGI no resuelve lo que estamos buscando. Cómo extender un modelo persistente y formularios existentes en tiempo de ejecución.