Ampliación de aplicaciones web Java con complementos

Question

Tengo esta aplicación web que se ha convertido en un desastre inmanejable.

Quiero dividirlo en una parte común de "estructura" (que todavía incluye elementos 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 un sistema de complemento para extensiones de terceros.

Todos los módulos deben ser unidades separadas de implementaciones, idealmente un archivo war o jar.

Intenté simplemente hacer varios archivos de guerra normales, pero Tomcat mantiene (de acuerdo con la especificación del servlet) estos archivos de guerra completamente separados el uno del otro, por lo que no pueden compartir sus clases, por ejemplo.

Necesito complementos para poder ver el classpath "principal".

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 dependencias) y cualquier otra aplicación web no relacionada que pueda estar ejecutándose en el mismo Tomcat.

Me gustaría que se enruten bajo el prefijo de URL de la aplicación "principal", pero eso no es necesario.

Me gustaría utilizar Tomcat (los grandes cambios arquitectónicos deben coordinarse con demasiadas personas), pero también para escuchar acerca de una solución limpia en el mundo EJB u OSGi, si los hay.

Answer 1

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

Answer 2

¿Ha considerado utilizar maven para separar sus proyectos y luego resolver las dependencias entre los WAR y los JAR? Terminará con la duplicación de bibliotecas entre WAR, pero solo donde sea necesario (y esto no debería ser un problema a menos que entres en alguna clase de funky classloader).

Tomcat también le permite configurar las aplicaciones de contexto cruz si es necesario obtener de una guerra a otra de una manera relativamente transparente ...

Si desea mantener las cosas bajo la misma aplicación web individual (por ejemplo RAÍZ) ¿podría crear una aplicación web de proxy que reenvíe a la otra aplicación de Internet relevante para que el usuario la vuelva relativamente transparente?

Answer 3

Su problema principal va a centrarse en los activos físicos y estáticos del sistema; el resto son simplemente jarras.

WARs están separados, en Tomcat, con cargadores de clases separados pero también están separados en el 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 se incluían en un EAR, compartirían classloaders (GF usa un espacio de cargador de clase plana en EAR), pero aún tendrían un estado de sesión separado.

Además, no estoy seguro si puede hacer un "reenvío" a otro WAR en el servidor. El problema es que los forwards usan 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 allí". Puedes redirigir, pero eso no es lo mismo que un forward.

Estas características de la aplicación web conspiran en su contra al intentar implementarlas de forma homogénea dentro del contenedor.

Más bien, creo que el consejo principal es crear una utilidad de "ensamblador" que tome sus módulos individuales y los "fusione" en una única aplicación web. Puede fusionar su web.xml, su contenido, normalizar las jarras y las clases, etc.

WARs son una característica y un error en el mundo de Java. Los amo porque realmente hacen que la implementación de aplicaciones compiladas "Arrastrar y soltar" en términos de instalación, y esa característica se utiliza mucho más de lo que estás encontrando. Pero siento tu dolor Tenemos un marco común "común" que compartimos entre las aplicaciones, y básicamente tenemos que fusionarlo continuamente para mantenerlo. Lo hemos escrito, pero sigue siendo un poco doloroso.

Answer 4

"Además, no estoy seguro de si puede hacer un" reenvío "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 puedes llegar hasta aquí". Puedes redirigir, pero eso no es lo mismo que un forward ".

Puede reenviar a otra WAR, siempre que esa GUERRA permita que alguien lo haga.

pez de cristal y WARs de un EAR: eso tiene sentido.

Si coloca las clases MAIN 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 de TOMCAT que usted define en server.xml. Este puede ser el SERVTER MASTER y todas las demás WAR pueden ser controladas por este servlet maestro.

¿Tiene sentido?

BR,
~ Un

Answer 5

Dependiendo de la complejidad de la funcionalidad plug-in también estaría considerando un servicio web, por ejemplo, implementado con el Eje.

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

La ventaja, tal como lo veo, es doble:

• Se obtiene una bonita limpia API,, depurable entre las dos guerras, es decir, los mensajes SOAP/XML
• Usted es capaz de actualizar un solo plug-in sin necesidad de regresión prueba su totalidad aplicación

Los disadvatages es que usted tiene que configurar algunos proyectos del Eje, y que usted tiene que tener algún tipo de plug-in configuración. Además, es posible que deba limitar el acceso a las aplicaciones web de sus servicios , por lo que podría necesitar un poco de configuración.

Si los complementos funcionan en la misma base de datos, asegúrese de limitar el tiempo de caché o configurar una capa de caché war-spanning .

Answer 6

Tome un vistazo a los portlets Java - http://developers.sun.com/portalserver/reference/techart/jsr168/ - en pocas palabras, una especificación que permite la interoperabilidad entre lo que son por lo demás aplicaciones web J2EE autónomos

Editar me olvidó mencionar que portlets son más o menos marco agnóstico: para que pueda usar Spring para la aplicación principal, y los desarrolladores individuales pueden usar lo que quieran en sus portlets.

Answer 7

También intentado desarrollar un marco común o abstracto en el que puedo añadir plugins (o módulos) en tiempo de ejecución y mejorar la aplicación de web funcionamiento existente.

Ahora, como usted ha dicho, ed manera de hacerlo mediante la guerra o archivo JAR preferido. Problema con el archivo WAR es que no se puede implementar como complemento a la aplicación existente. Tomcat lo desplegará como un contexto web separado. No deseable.

Otra opción es archivo JAR y escribir código personalizado para copiar ese archivo JAR en WEB-INF/lib y cargar las clases en las cargador de clases existente. El problema es cómo implementar archivos que no son de 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.

OSGI o primavera módulos dinámicos son agradables, pero en este momento, se ven demasiado complejo para mí. Investigaré eso nuevamente, si lo siento.

Busco API simple, que puede hacerse cargo de ciclo de vida del plugin y siendo capaz de utilizar JSP en mi archivo JAR envasados.

Puede ser, puede utilizar el plugin tarro de las Naciones Unidas en el despliegue de tiempo y copiar los archivos a los directorios adecuados.

Answer 8

Realmente 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 (core) donde incluya tarros que necesite su aplicación.

Si sabe algo acerca de 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 cómo 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 debe verificar qué versión de jar está cargada para sus necesidades.

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