outside - load properties file java resources

¿Es una mala práctica incluir propiedades/archivos de configuración dentro de los tarros? (11)

Por ejemplo:

MyApp es una aplicación web que contiene un archivo de propiedades (server.properties) que describe datos de configuración (por ejemplo, nombres de servidor) para la aplicación. En la fase de desarrollo, server.properties se encuentra en su propia carpeta de proyectos IDE (un lugar lógico para ello).

Ahora es el momento de implementar MyApp. El IDE hace que sea bastante trivial agrupar los archivos de clase así como los archivos de configuración compatibles. Ahora solo dejamos caer el Jar en el contenedor web apropiado y nos vamos ...

Una semana después ... los datos de configuración del servidor que usa MyApp deben cambiar. ¿Qué tiene más sentido?

A. Modificar el archivo server.properties de nuevo en el terreno IDE y generar un archivo jar completamente nuevo. Volver a desplegar (lo que significa rebotar la aplicación para un cambio de configuración simple).

B. ¿Desea abrir el Jar ya implementado y modificar el archivo server.properties? (puede que tenga que llamar a una función de actualización en MyApp si server.properties está en caché ... pero no debería requerir un rebote completo de la aplicación. También debe recordar modificar la fuente de server.properties también para que las implementaciones futuras no reviertan server.properties a los antiguos nombres de servidor).

C. Hacer server.properties externo al archivo jar en primer lugar. Muy similar al proceso de B, con la pequeña diferencia de mantener los datos de configuración externos al contenedor (introduce diferentes rutas entre los despliegues de desarrollo y producción)

D. Otro:

¡Gracias!

Con frecuencia, es un criterio que el código debe migrarse SIN CAMBIAR de la prueba a la producción. Esto implica que no puede editar archivos de configuración incrustados. También puede terminar en una situación en la que necesite cambiar una configuración implementada, lo que a menudo es muy engorroso. Por lo tanto, dejamos la configuración fuera de los frascos.

Para aplicaciones Java EE, considere JNDI o un archivo de propiedades en la ruta de clase.

Tengo una aplicación web donde la configuración se recupera de una aplicación web vecina simplemente para separar los dos. Eso resultó ser mucho más fácil.

Creo que la respuesta depende de si cree que necesita un control de versión para las configuraciones. (Pueden ser configuraciones de producción o configuraciones para pruebas de regresión ...)

Si no necesita el control de versiones, la opción D con un archivo de propiedades externo que invalida un archivo de propiedades es buena. Las opciones B y C están más abiertas a los problemas, pero si realmente te importara, estarías usando el control de versiones :-)
Si necesita el control de versiones, la opción A le brinda más control, pero si tiene la posibilidad de realizar múltiples implementaciones, también puede querer / necesitar el control de versiones de las configuraciones para cada implementación. Un ejemplo son las implementaciones separadas para probar y plataformas de producción.

Así es como lo hacemos utilizando los módulos de Maven y las "superposiciones" del archivo WAR de Maven.

Tenemos múltiples módulos para los componentes de código Java. Estos son los módulos JAR.
Contamos con el módulo "base webapp" para el contenido estático, JSP y datos de configuración del núcleo (cableado de Spring, propiedades predeterminadas). Este es un módulo WAR, por lo que el resultado de la construcción es un WAR que contiene lo anterior + todos los archivos JAR.
Cada "configuración del sitio" es un módulo WAR que contiene modificaciones específicas del sitio para las propiedades, los archivos de cableado y el contenido. La anulación se describe mediante el mecanismo de "superposición" WAR de Maven, y da como resultado un nuevo WAR que se ensambla a partir de la WAR "base" y las anulaciones.

Todo esto está incluido en el control de versiones, y debe realizar una implementación de Maven y WAR para realizar cambios en la configuración.

Depende. Si el archivo de propiedades contiene datos que deben ser modificados por el usuario de su aplicación o biblioteca, estos deben residir en el exterior.

Si contiene datos estáticos y usted creó los archivos de propiedades solo para evitar la codificación de los valores en el código fuente o si los archivos son cadenas localizadas, los dejo en el contenedor. Al menos porque un archivo de propiedades invita a las personas a cambiar valores;)

Desarrollo aplicaciones J2EE utilizando Spring. Estuve repitiendo el mismo problema durante bastante tiempo y luego encontré una solución. Mi problema fue especificar las propiedades de la base de datos en un archivo de propiedades fuera del archivo war que implemento. La solución que encontré para esto es usar el PropertyPlaceholderConfigurer y especificar la propiedad de ubicación para ubicar la ubicación de su sistema como esta,

Esto fue bastante simple y funcionó bien!

He hecho una pregunta similar. Todavía no lo hemos resuelto todo. Pero estamos buscando en los recursos de URL. Donde el archivo de propiedad se lee directamente desde SVN. No es necesario actualizar nada más que el archivo de propiedades.

Opción D. En diferentes entornos, es posible que deba especificar que desea especificar las propiedades del entorno, como conectarse a la base de datos o al proxy, etc.

Otra cosa que vale la pena mencionar es que en producción es posible que desee cambiar rápidamente una propiedad sin tener que empaquetar previamente un frasco o reemplazar el archivo de propiedades en el frasco.

Por ejemplo, el servidor de la base de datos se ha caído y debe apuntar a un servidor diferente (si no utiliza un equilibrador de carga de las bases de datos). Así que todo lo que necesita hacer es reemplazar las propiedades de la base de datos y reiniciar. Ahorrarás mucho tiempo allí.

RE.

Cargar las propiedades en el tarro. Luego cree una nueva Propiedades usando las propiedades de jarra como las predeterminadas. A continuación, cargar desde el exterior de la jarra. Esto permite seleccionar la personalización de las propiedades.

Recuerde que en J2EE, NO se le garantiza que pueda acceder a los archivos desde fuera del entorno J2EE (sin acceso directo a los archivos).

Tendría que usar JNDI para apuntar a una fuente de datos que contenga sus datos, o un archivo de propiedades en sus artefactos de implementación.

Websphere, por ejemplo, no permite el acceso directo a archivos de forma predeterminada.

Si está utilizando Spring, entonces puede hacer uso del marcador de posición de la propiedad para hacer el trabajo.

 <context:property-placeholder location="file:config.properties, classpath:config.properties" ignore-resource-not-found="true"/>

Puede especificar un recurso en el sistema de archivos y también en la ruta de clase, Spring primero intentará resolver todas las propiedades del sistema de archivos y luego volverá a la ruta de clase. Al especificar el atributo "ignorar-recurso-no-encontrado" como "verdadero" evitará que Spring lance una excepción si el archivo no está presente en el sistema de archivos y le permite resolver las propiedades de la ruta de clase.

El uso de esta combinación también le permite dividir las propiedades en dos archivos, por ejemplo, es posible que nunca desee especificar las contraseñas en el archivo en el classpath y esperar que se especifiquen externamente en el sistema de archivos. Cualquier propiedad que falte en el sistema de archivos se resolverá desde la ruta de clase.

En una carpeta que contiene:

application.jar config.properties

Deberías poder usar:

java -jar application.jar

Este es un ejemplo de config.properties para referencia:

# This file contains properties that are used to configure the application database.url=127.0.0.1 database.port=3306 database.user=root database.pass=p4ssw0rd

Uso archivos de propiedades en aplicaciones web (WAR), pero principalmente para valores predeterminados y cosas más o menos inmutables (ya que las aplicaciones web no deberían actualizar sus archivos WAR incluso cuando pueden).

Para cosas como de lo que estás hablando, sin embargo, uso JNDI. Puede definir las propiedades como recursos en su archivo web.xml. De esa manera, en el peor de los casos, actualiza web.xml y no la aplicación en sí.

Para algunos servidores, hay formas de anular estos valores de recursos sin tocar el WAR en absoluto. Por ejemplo, en Tomcat.

Normalmente hago un WAR para prueba, Q / A y producción y anulo los recursos sensibles al medio ambiente exactamente con esto, utilizando los archivos xml Context de Tomcat. Considero que esto es mucho mejor que tener que crear múltiples WAR o modificar WARS, ya que la aplicación que estoy probando es casi idéntica a la que está en producción.

Yo iría con D.

Intente cargar los archivos de propiedades desde fuera del archivo .jar y luego, si eso falla, cargue las propiedades integradas en el jar.

Esto le permite llevar a cabo una configuración "lista para usar" con cada compilación (también reduce la complejidad de una implementación, aunque solo sea por un archivo), al mismo tiempo que hace que las configuraciones primordiales sean posibles y razonablemente simples.