¿Está bien poner archivos de configuración en JAR?

Question

Estamos teniendo un debate en mi oficina sobre lo que puede y no puede ir en un archivo JAR. Se ha sugerido que es mala forma tener todo lo que no sea un archivo .class en un archivo JAR. Actualmente tenemos algunas configuraciones XML para Ibatis/etc, algunos archivos de propiedades ... lo de siempre. Sin embargo, existe un impulso para extraer todos esos archivos de los JAR y colocarlos en el sistema de archivos local de cada máquina de despliegue. ¿Esto suena razonable?

Answer 1

No me parece razonable. Creo que la configuración de algunas aplicaciones debe estar en el archivo jar. Cosas tales como correlaciones de ORM, configuración de primavera, espacio de nombres de primavera personalizado XSD, otros XSD, etc. deberían estar en la mayoría de los casos en jar. Es una parte importante del artefacto de implementación.

El hecho de que no sea el archivo class, no significa que deba sacarse del contenedor simplemente porque teóricamente se puede modificar sin crear un nuevo contenedor. ¿Te imaginas una modificación de * .hbm.xml en producción? para mí suena muy aterrador.

Creo que algunas configuraciones, como spring xml, se refieren en la mayoría de los casos a una mejor organización de su aplicación y dependencias, pero no a cambiarlas en tiempo de ejecución en producción.

Answer 2

Si realiza cambios en un archivo de configuración dentro de un JAR (incluso sin alterar ninguna línea de código Java), se debe reconstruir y volver a implementar todo el JAR. ¿Esto suena razonable?

Answer 3

¿Desea o espera que se modifiquen sin una nueva versión del código? Entonces necesitas extraerlos.

Si la respuesta a la pregunta no es que no debe extraerlos, ya que permitiría soporte para jugar con ellos sin pasar por el proceso de lanzamiento. (Por supuesto, esto también es posible si están en el JAR, pero un poco menos tentadores.)

Actualización: Pero como mencionó varias máquinas de implementación, hay una tercera opción: extraerlas y colocarlas en un área comúnmente accesible en una unidad de red. Los archivos de configuración editables manualmente que se replican en varias máquinas (pero deberían ser idénticos) son notorios por no estar sincronizados.

Answer 4

es mala forma de tener todo lo que no es un archivo .class entrar en un JAR

Eso no tiene sentido. De hecho, es muy forma buena para poner recursos como iconos y otros archivos de datos que el usuario utiliza por el código en el JAR junto con el código. Para esto sirven los métodos getResource() y getResourceAsStream() de Class y ClassLoader, y ofrece aplicaciones mucho más robustas que las que dificultan las rutas de recursos manualmente.

Sin embargo, archivos de configuración son posiblemente una cuestión diferente. Si están destinados a ser cambiados durante o después del despliegue, entonces tenerlos dentro de un archivo JAR es bastante inconveniente, y es preferible tenerlos en un directorio separado.

Answer 5

No se supone que las herramientas ORM (como Hibernate o IBatis) se modifiquen una vez que se implementa la aplicación. Entonces, no, yo diría que no tiene sentido para ese tipo de archivos.

Dependiendo de sus requisitos, los archivos de configuración de toda la aplicación se pueden colocar fuera del Jar/War para que puedan modificarse sin tener que reconstruir el contenedor. Tenga en cuenta que modificar los parámetros de la aplicación en producción es, en mi opinión, una mala práctica. Los cambios deben probarse primero en algún entorno de preproducción.

Answer 6

Es absolutamente bien para poner archivos que no son de clase en un fichero JAR, especialmente los recursos que necesita la aplicación (imágenes, cadenas localizadas, etc.) Sabiendo esto, usted debe decidir qué escenario se adapte a su situación:

• Si la configuración es fija y solo cambiará cuando se implemente un nuevo archivo JAR, colóquelo en el JAR.
• Si la configuración debe ser alterada, ya sea manualmente o por la aplicación, guárdela en el sistema de archivos.

Si elige este último, tenga en cuenta que es una buena práctica incluir una configuración por defecto en el archivo JAR para manejar el caso cuando el archivo de configuración externa no se encuentra. El valor predeterminado puede cargarse directamente desde el JAR o copiarse en el sistema de archivos para convertirse en la nueva configuración editable.