2012-03-07 9 views
10

Estoy trabajando en la reescritura de algunas aplicaciones web antiguas. Hay dos en particular que son muy, muy similares, pero no comparten código hoy y mi objetivo es solucionarlo.Mejores prácticas para compartir código de nivel web (controladores y JSP) entre aplicaciones web similares

Los proyectos están siendo reescritos con Maven, Spring MVC, y SiteMesh.

El código de nivel de modelo es fácil de compartir utilizando JAR. Pero no conozco ninguna buena forma de compartir un código común de nivel web (JSP y controladores) entre aplicaciones similares.

A continuación, algunos antecedentes. Estas aplicaciones son tiendas web. Una de ellas es una tienda normal (piense amazon.com) en la que un usuario puede iniciar sesión, buscar productos, agregar a un carrito de compras y retirar. El otro es básicamente lo mismo, solo que es un sitio punchout. Las porciones de exploración del producto y del carrito de compras son idénticas. Registrarse y pagar, sin embargo, son completamente diferentes.

estoy simplificando demasiado, pero es suficiente para ilustrar el problema. Hay una porción significativa de código de nivel web en las secciones de exploración de productos y carrito de compras que deberían poder compartirse entre los dos.

no creo que es posible simplemente tener el mismo archivo WAR funcionando como "modo" basado en una variable de entorno o la configuración de una base de datos diferente. Una de las diferencias es una configuración Spring Security completamente diferente. También sería preferible dejar los controladores de entrada y salida del otro sitio fuera del escaneo de componentes para que nadie pueda pasar de alguna manera al que está equivocado con la manipulación de URL.

originalmente empecé a usar los perfiles de Maven y filtrado para mantener dos conjuntos de configuración diferentes (web.xml, configs de primavera, etc.) en el mismo proyecto GUERRA. Según el perfil de Maven seleccionado, el WAR resultante se construye con un conjunto de configuración diferente (y un nombre diferente para mayor claridad). Esto viola el principio Maven de que un pom produce un artefacto.

¿Hay una mejor manera de hacerlo? ¿Qué pasa con Maven WAR Overlays? Veo gente hablando de usar superposiciones para compartir recursos comunes como CSS, JS, imágenes e incluso algunos JSP comunes. Pero no veo a nadie mencionar compartir clases como controladores de esta manera.

pude empujar las clases controlador hacia abajo a los frascos, pero lógicamente parece que deberían permanecer con sus respectivas páginas JSP. Y las JSP tampoco se pueden bajar a los JAR (¿verdad?).

También pensé en lo que es un EAR que contiene varios archivos WAR - Primera Guerra de la experiencia de compra común, y otra guerra para el inicio de sesión y registro de salida apropiada. Creo que la sesión se puede compartir entre dos WAR en el mismo EAR, pero no estoy seguro de si funciona bien con los beans de alcance de sesión de Spring. Escuché que no están realmente almacenados en la sesión. También tendría que averiguar qué hacer con los decoradores de Sitemesh que se usan para el encabezado/pie de página. La misma configuración de Sitemesh y sus recursos necesitarían ser copiados en ambos WARs, ¿verdad? Entonces, al final, el artefacto WAR de compras aún sería diferente en cada circunstancia.

Tengo que creer que otras personas han tratado esto antes. ¿Estoy pensando en eso de la manera incorrecta? ¿Hay una solución común para este tipo de cosas?

Respuesta

1

Buen trabajo luchando contra copiar y pegar. ¿Por qué dices que es difícil compartir JSP? Puede copiarlos de un tarro compartida utilizando la dependencia plugin de Maven:

<plugin> 
     <groupId>org.apache.maven.plugins</groupId> 
     <artifactId>maven-dependency-plugin</artifactId> 
     <version>2.4</version> 
     <executions> 
      <execution> 
      <id>unpack</id> 
      <phase>package</phase> 
      <goals> 
       <goal>unpack</goal> 
      </goals> 
      <configuration> 
       <artifactItems> 
       <artifactItem> 
        <groupId>com.example</groupId> 
        <artifactId>webapp-common</artifactId> 
        <version>1.0-SNAPSHOT</version> 
        <outputDirectory>[target jsp directory]</outputDirectory> 
        <includes>**/*.jsp</includes> 
       </artifactItem> 
       </artifactItems> 
      </configuration> 
      </execution> 
     </executions> 
     </plugin> 
+0

Este es un buen truco, y puedo terminar yendo con él sinc e No nos veo nunca renunciar a Maven. El único inconveniente que se hizo inmediatamente evidente es que los desarrolladores ya no pueden actualizar un JSP sobre la marcha si se copia de un JAR. Se necesita una reconstrucción y una nueva implementación desde el IDE para ver una edición simple. Dudo que haya algo que se pueda hacer al respecto, pero soy todo oídos si tienes una idea. – KevinF

+0

Bueno ... podría hacer algo sucio con enlaces simbólicos, probablemente, dependiendo de lo diferente que esté preparado para hacer su entorno de desarrollo del artefacto final. O bien, si está utilizando un WAR explosionado, no tardará en ejecutarse el objetivo de 'unpack' de maven por sí solo después de cada JSP. – artbristol

0

Mi opción preferida en estos casos se pone todos los archivos relacionados (controladores, JS, imágenes ...) en un frasco.Pero el problema aquí es el uso de los archivos JSP: no hay una manera fácil de usarlos si están en un contenedor. Pero con otras tecnologías de visualización como Velocity o Freemarker esto es posible de una manera sencilla, entre otras ventajas. No sé si esto puede llevarte a trabajar demasiado, pero para un nuevo proyecto con estas necesidades es la mejor opción.

+0

Interesante ... ¿así que está diciendo que podríamos extraer plantillas de Velocity/Freemarker de/WEB-INF/velocity o de un JAR? ¿Eso requeriría un ViewResolver personalizado para lograr con Spring MVC? Todos los ejemplos que encuentro se refieren a/WEB-INF. – KevinF

+0

Aquí tienes un buen ejemplo: http://www.springbyexample.org/examples/velocity-email-template.html – sinuhepop

0

Estamos utilizando Subversion aquí, y usamos svn: externals (tipo de enlaces simbólicos) para compartir cierto código común (principalmente archivos .jsp) entre proyectos. Funciona bastante bien, estábamos usando OC4J que en realidad tiene una forma de compartir archivos .jsp entre varios proyectos, pero como actualmente estamos avanzando hacia Tomcat (u otra cosa), quería encontrar una forma de agnóstica de contenedor para hacerlo.

0

Sinuhepop tiene razón, pero su respuesta no es perfecta.

Aquí está la respuesta perfecta. tienes que referir la url de seguimiento, puede ayudarte.

click here

en el URL de la página, el ejemplo para el cuadro de contenido de la propiedad no es exacta, me siguen:

si necesidad de compartir un archivo:

a.jsp svn://myhome.com/svn/myproject/trunk/a.jsp 

si es necesario compartir una carpeta:

xml svn://myhome.com/svn/myproject/trunk/xml 
Cuestiones relacionadas