¿Dónde van los archivos de configuración de Spring Bean en un módulo WAR de Maven?

Question

He visto un montón de ejemplos de proyectos y parece que no puedo extraer una buena práctica común. He visto los archivos de configuración Spring Bean a veces en el directorio src/main/webapp/WEB-INF. He visto esto en conjunto con una definición de servlet en web.xml así:

<servlet> 
    <servlet-name>my-stuff</servlet-name> 
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> 
    <init-param> 
     <param-name>contextConfigLocation</param-name> 
     <param-value>/WEB-INF/my-stuff-servlet.xml</param-value> 
    </init-param> 
    <load-on-startup>1</load-on-startup> 
</servlet> 

Pero también he visto los archivos de configuración de frijol incluyen dentro web.xml nivel superior - es decir, fuera de un servlet. ¿Qué significa esto? ¿Esto es para frijoles Servlet cruzados? A veces está en el directorio src/main/webapp/WEB-INF y, a veces está en src/main/resources. También he visto otros archivos de configuración de beans definidos en los módulos WAR con casi todo en src/main/resources.

He leído y releído la documentación de Spring, pero la única convención que encontré es que, de forma predeterminada, un archivo de configuración de contexto Servlet debe estar en el directorio src/main/webapp/WEB-INF llamado {servlet-name}-servlet.xml.

¿Cuál es la mejor práctica y por qué?

Answer 1

Los contextos de aplicación en Spring pueden formar jerarquías donde el contexto secundario tiene acceso a los beans definidos en el contexto primario.

Una aplicación web típica Spring MVC contiene una jerarquía con dos niveles:

contexto de aplicación web

• Root cargado por ContextLoaderListener. La ubicación de configuración de este contexto es applicationContext.xml de forma predeterminada y se puede configurar usando <context-param> llamado contextConfigLocation, es decir, en el nivel superior de web.xml. Este contexto generalmente contiene una lógica de aplicación central.

• Servlet-specifc contexto cargado por DispatcherServlet. Su ubicación de configuración es por defecto <servletname>-servlet.xml y se puede configurar usando <init-param> llamado contextConfigLocation, es decir, a nivel de servlet. Este contexto generalmente contiene un material relacionado con Spring MVC (controladores, etc.) ya que DispatcherServlet forma parte de Spring MVC.

El último contexto es un hijo de la primera.

Si la aplicación web no utiliza Spring MVC como marco de presentación, no tiene DispatcherServlet ni su contexto. Algunas muestras de Spring MVC extremadamente simples no tienen ContextLoaderListener y el contexto raíz (sin embargo, necesita un contexto raíz para la funcionalidad de servlets cruzados, como Spring Security).

Los archivos de configuración de la aplicación web se encuentran por defecto en la carpeta raíz de la aplicación web. Sin embargo, pueden colocarse en el classpath (es decir, en src/main/webapp), en este caso se accede a través del prefijo classpath:. Esto puede ser útil si va a utilizar algunos de estos archivos en pruebas de integración sin contenedor de servlets. También el prefijo classpath: puede ser útil cuando desee cargar un archivo de configuración desde un artefacto separado, es decir, desde un archivo jar en /WEB-INF/lib.

Answer 2

Creo que a menudo es un buen estilo mantener el código, su configuración de resorte en un JAR separado que está incluido en el WAR, de modo que el WAR está básicamente vacío, pero para web.xml y similares. Esto le evita incluso hacer esta pregunta. :-) Puedes hacer referencia a esas configuraciones de primavera con classpath: prefix.

Una ventaja de este diseño es que puede escribir fácilmente Unittest que instancia la configuración de Spring completa de WAR dentro del JAR. No necesariamente recomendaría usar esto para las pruebas reales (aunque puede hacer pruebas de integración de esta manera), pero obtendrá una respuesta rápida cuando accidentalmente rompa la estructura general de los archivos de configuración sin tener que volver a desplegar la aplicación.

Si realmente necesita poner archivos de configuración de resorte en el WAR (quizás porque también hace referencia a los beans que se implementan en el WAR) también los pondría en la ruta de recursos normales/WEB-INF/classes, para el razones discutidas arriba.