¿Cómo muevo mi configuración spring xml fuera de mi aplicación web java?¿Cómo muevo la configuración Spring xml fuera de mi aplicación web?
Me gustaría almacenar mi spring.xml fuera de mi aplicación web para no tener que crear una nueva compilación de mi aplicación para cambiar la configuración.
¿Cuál es la mejor manera de hacerlo?
Como Rod Johnson lo explica en this thread:
Puede utilizar el prefijo
classpath:cargar de la ruta de clases, con el oyente primavera normal o servlet inicio. Esto es posible gracias a la abstracción de recursos de Spring. Puede mezclar y combinar libremente recursos deWEB-INFy classpath.
lo tanto, poner los archivos de configuración en algún lugar de la ruta de clase fuera de la aplicación web y declarar lo siguiente en el web.xml:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:springContext*.xml</param-value>
</context-param>
creo que confiar en la ruta de clase es más portátil que utiliza una ruta de archivo absoluta .
Eso definitivamente sería un buen enfoque para la aplicación independiente. Sin embargo, para webapp, para tener algo en classpath pero fuera de la carpeta webapp deberías hacer que tu contexto esté disponible para todo el servidor, lo que puede no ser ideal (a menos que la aplicación en cuestión sea la única). – ChssPly76
Para ser más precisos, esto significa hacer que los archivos de contexto estén disponibles para todas las aplicaciones web (no estoy seguro de que esto sea lo que quería decir con "servidor completo"). Pero estoy de acuerdo en que esto puede no ser ideal. –
Puede moverlo a alguna carpeta (fuera de la estructura de aplicación de web) y especificar explícitamente la ubicación de contexto para señalar contexto en esa carpeta en su web.xml:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>file:/full/path/to/context.xml</param-value>
</context-param>
Dicho esto, el mejor manera de hacerlo esto puede ser no hacerlo en absoluto :-) y en su lugar reconsiderar cómo despliega su aplicación (por ejemplo, puede crear un "parche" o una unidad de implementación de "actualización" que contenga cambios en lugar de una GUERRA completa). Especificar rutas absolutas tiende a ser más complicado de lo que vale.
Por qué complicar la compilación para esto, cuando se trata de un problema de implementación. La mayoría de los contenedores implementan WAR en una forma "explosionada", lo que significa que en algún lugar de su sistema de archivos está el archivo spring.xml.
Si desea actualizar eso, puede simplemente localizar la ubicación real y luego copiar su nuevo spring.xml sobre el anterior. Sin embargo, al mismo tiempo, su GUERRA sigue siendo la "fuente de la verdad" de riguer.
Los WAR son muy sencillos de usar y desplegar, por lo que la configuración de WAR es lo mejor posible.
Por lo tanto, puede actualizar el archivo spring.xml yendo detrás de la parte posterior del contenedor y editando (o copiando) directamente.
Finalmente, tener el archivo spring.xml fuera de su WAR significa que está disponible para TODOS sus WAR, y si luego decide agregar otro WAR a su sistema, es probable que tenga dificultades para segregar los dos archivos, ya que son no mucho tiempo anclado a una GUERRA específica.
Estamos de acuerdo en que esto es un problema de implementación. Sin embargo, te equivocas sobre que el contexto esté disponible para todos los WAR, ¿por qué sería? – ChssPly76
Creo que quiere decir que dos copias de la misma GUERRA se referirían al mismo archivo en el sistema de archivos ... no parece una razón convincente para no hacerlo, aunque – skaffman
Implementaremos esto.guerra a múltiples clientes con diferentes configuraciones. Es por eso que necesitamos un archivo de configuración externo. – ScArcher2
¿dónde te gustaría guardarlo, idealmente? – skaffman
Idealmente, usaríamos una variable pasada a tomcat para determinar su ubicación. Sin embargo, un camino codificado duro es una alternativa aceptable. – ScArcher2