java - descompilar - diferentes archivos WAR, recursos compartidos

descompilar war

Question

Supongamos que tiene varias aplicaciones que comparten el mismo código y la mayoría de los otros recursos, pero que tienen un aspecto y sensación algo diferentes, algunas etiquetas cambian, etc. (piense en la marca). Si cada aplicación web debe ir en su propio archivo WAR, ¿dónde colocas los recursos compartidos?

Ya uso el classpath para compartir clases y archivos de propiedades. ¿Pero qué pasa con los archivos javascript y css? ¿Es la mejor manera de crear y desplegar un archivo WAR adicional que servirá estos archivos compartidos a cualquier otra aplicación que los requiera?

También pensé en un script de compilación que hace algo de magia y de una fuente común arroja los WAR (ligeramente) diferentes, pero no me gusta porque complica las cosas innecesariamente cuando necesitas construir / probar / ejecutar una sola aplicación .

Cualquier otro consejo y trucos sería apreciado.

Answer 1

Actualizar

Sí, yo de nuevo. En realidad, he cambiado de opinión (nuevamente :)). Actualmente estoy intentando (siendo más prudente aquí):

• (Común) GUERRA: que contiene la aplicación, común (la mayoría de las partes) + algunas cosas específicas
• EAR1: CommonWAR + archivo de configuración específico para env1
• EAR2: CommonWAR + archivo de configuración específico para env2

El archivo de configuración es recogido por WAR. Está en el classpath EAR y solo contiene una propiedad ''application'' con un valor. La única GUERRA utilizará esta información cuando sea apropiado para distinguir entre las dos aplicaciones (configuración, hojas de estilo, ...).

Con mi solución de EAR1 = CommonWAR + WAR1, EAR2 = CommonWAR + WAR2, era muy difícil o imposible buscar recursos estáticos en el CommonWAR sin usar una url web (por ejemplo, imágenes en documentos PDF generados con iText).

Answer 2

Puede desplegar ambos WAR en el mismo EAR y poner recursos comunes en el EAR. A continuación, coloque las dependencias apropiadas en el manifiesto de las aplicaciones web para vincular los archivos jar al oído.

Answer 3

Si no quiere ir a la ruta EAR, usando tomcat, etc; hay algunas otras formas de lograr la coherencia que desea.

Si quieres compartir solo js y css, investiga pack: tag . Puede alojar .js y css desde un servidor apache, configurar su httpd.conf para que sus aplicaciones web puedan llamarlo, luego use pack: tag de sus guerras de aplicaciones - DRY y compresión en un solo paso.

Answer 4

Gracias por las respuestas hasta ahora, pero me temo que olvidé mencionar que los WAR se desplegarán en diferentes entornos que están completamente aislados unos de otros.

Entonces, quizás tener una WAR común desplegada junto a la aplicación real es la única opción. Creo que iré con lo siguiente:

• WAR1, WAR2 contiene material específico de la aplicación
• CommonWAR que contiene cosas comunes (no es broma)
• EAR1: WAR1 + CommonWAR, para implementarse en env1
• EAR2: WAR2 + CommonWAR, para implementarse en env2

Answer 5

Una estrategia que he visto utilizar para tales configuraciones de línea de producto es usar superposiciones WAR cuando se construye con maven . Define una GUERRA común que contiene las cosas comunes y la superpone con esas otras GUERRAS que contienen las cosas específicas para generar diferentes WAR para cada aplicación. Este método es probablemente más útil si despliega las variantes WAR en diferentes máquinas. Pero no estoy seguro de si realmente puedo recomendar esto.

Recuerde especificar la configuración de las superposiciones si realmente anula las cosas, ya que, de lo contrario, el orden de anulación no es determinista. Incluso podría cambiar con una actualización maven-war-plugin. (Lo hizo en nuestro caso)

Answer 6

¿Qué le parece poner su css y js en el classpath y servirlos con un servlet? A continuación, puede compilar los recursos comunes como un jar y ese jar incluso puede contener el servlet (dispatcher de recursos si lo desea) y los archivos war pueden contener el archivo jar en la carpeta WEB-INF / lib.