propiedades con Spring y Spring Boot

registrar un archivo de propiedades a través de anotaciones

Spring 3.1 también introduce la nueva anotación @PropertySource como un mecanismo conveniente para agregar fuentes de propiedades al entorno.,

Podemos usar esta anotación junto con la anotación @Configuration:

@Configuration@PropertySource("classpath:foo.properties")public class PropertiesWithJavaConfig { //...}

otra forma muy útil de registrar un nuevo archivo de propiedades es usando un marcador de posición, que nos permite seleccionar dinámicamente el archivo correcto en tiempo de ejecución:

@PropertySource({ "classpath:persistence-${envTarget:mysql}.properties"})...

2.1. Definir varias ubicaciones de propiedades

la anotación @PropertySource es repetible de acuerdo con las convenciones de Java 8., Por lo tanto, si estamos usando Java 8 o superior, podemos usar esta anotación para definir múltiples ubicaciones de propiedades:

Por supuesto, también podemos usar la anotación @PropertySources y especificar una matriz de @PropertySource. Esto funciona en cualquier versión compatible de Java, no solo en Java 8 o superior:

en cualquier caso, vale la pena señalar que en el caso de una colisión de nombre de propiedad, la última fuente leída tiene prioridad.,

usar/inyectar propiedades

inyectar una propiedad con la anotación @Value es sencillo:

@Value( "${jdbc.url}" )private String jdbcUrl;

También podemos especificar un valor predeterminado para la propiedad:

@Value( "${jdbc.url:aDefaultUrl}" )private String jdbcUrl;

El Nuevo PropertySourcesPlaceholderConfigurer se agregaron en Spring 3.1 Para resolver marcadores de posición {{}} dentro de los valores de propiedad de Bean definition y las anotaciones @value.,

finalmente, podemos obtener el valor de una propiedad usando la API de entorno:

@Autowiredprivate Environment env;...dataSource.setUrl(env.getProperty("jdbc.url"));

propiedades con Spring Boot

antes de entrar en Opciones de configuración más avanzadas para propiedades, pasemos un tiempo mirando el nuevo soporte de propiedades en Spring Boot.

en términos generales, este nuevo soporte implica menos configuración en comparación con el muelle estándar, que es, por supuesto, uno de los principales objetivos de Boot.

4.1. aplicación.,propiedades: el archivo de propiedades predeterminado

Boot aplica su método típico de Convención sobre configuración a los archivos de propiedades. Esto significa que podemos simplemente poner una aplicación.archivo de propiedades en nuestro directorio src / main / resources, y se detectará automáticamente. Entonces podemos inyectar cualquier propiedad cargada de ella como normal.

por lo tanto, al usar este archivo predeterminado, no tenemos que registrar explícitamente un PropertySource o incluso proporcionar una ruta a un archivo de propiedad.,

también podemos configurar un archivo diferente en tiempo de ejecución si lo necesitamos, utilizando una propiedad de entorno:

java -jar app.jar --spring.config.location=classpath:/another-location.properties

a partir de Spring Boot 2.3, también podemos especificar ubicaciones comodín para los archivos de configuración.

por ejemplo, podemos establecer el resorte.config.location property to config/*/:

java -jar app.jar --spring.config.location=config/*/

de esta manera, Spring Boot buscará archivos de configuración que coincidan con el patrón del directorio config / * / fuera de nuestro archivo jar. Esto es útil cuando tenemos múltiples fuentes de propiedades de configuración.

Desde la versión 2.4.,0, Spring Boot admite el uso de archivos de propiedades de varios documentos, de manera similar a como lo hace YAML por diseño:

baeldung.customProperty=defaultValue#---baeldung.customProperty=overriddenValue

tenga en cuenta que para los archivos de propiedades, la notación de tres guiones está precedida por un carácter de comentario (#).

4.2. Archivo de propiedades específicas del entorno

Si necesitamos apuntar a diferentes entornos, hay un mecanismo incorporado para eso en el arranque.

simplemente podemos definir un entorno de aplicación.archivo de propiedades en el directorio src / main / resources, y luego establezca un perfil Spring con el mismo nombre de entorno.,

por ejemplo, si definimos un entorno «staging», eso significa que tendremos que definir un perfil staging y luego application-staging.propiedad.

Este archivo env se cargará y tendrá prioridad sobre el archivo de propiedades predeterminado. Tenga en cuenta que el archivo predeterminado todavía se cargará, es solo que cuando hay una colisión de propiedades, el archivo de propiedades específicas del entorno tiene prioridad.

4.3. Archivo de propiedades específicas de la prueba

es posible que también tengamos un requisito para usar diferentes valores de propiedad cuando nuestra aplicación está bajo prueba.,

Spring Boot maneja esto por nosotros buscando en nuestro directorio src/test/resources durante una ejecución de prueba. Una vez más, las propiedades predeterminadas seguirán siendo inyectables como normales, pero serán anuladas por estas si hay una colisión.

4.4. La anotación @TestPropertySource

Si necesitamos un control más granular sobre las propiedades de la prueba, entonces podemos usar la anotación @TestPropertySource.,

esto nos permite establecer propiedades de prueba para un contexto de prueba específico, teniendo prioridad sobre las fuentes de propiedades predeterminadas:

si no queremos usar un archivo, podemos especificar nombres y valores directamente:

También podemos lograr un efecto similar utilizando el argumento properties de la anotación @SpringBootTest:

4.5. Propiedades jerárquicas

Si tenemos propiedades agrupadas, podemos hacer uso de la anotación @ConfigurationProperties, que mapeará estas jerarquías de propiedades en gráficos de objetos Java.,

tomemos algunas propiedades utilizadas para configurar una conexión de base de datos:

database.url=jdbc:postgresql:/localhost:5432/instancedatabase.username=foodatabase.password=bar

y luego usemos la anotación para mapearlas a un objeto de base de datos:

Spring Boot aplica su Convención sobre el enfoque de configuración nuevamente, mapeando automáticamente entre los nombres de propiedades y sus campos correspondientes. Todo lo que necesitamos suministrar es el prefijo de propiedad.

Si desea profundizar en las propiedades de configuración, eche un vistazo a nuestro artículo en profundidad.

4.6. Alternativa: archivos YAML

Spring también admite archivos YAML.,

se aplican las mismas reglas de nomenclatura a los archivos de propiedades predeterminadas, específicos del entorno y específicos de la prueba. La única diferencia es la extensión del archivo y una dependencia de la biblioteca SnakeYAML que está en nuestro classpath.,

YAML es particularmente bueno para el almacenamiento jerárquico de propiedades; el siguiente archivo de propiedades:

database.url=jdbc:postgresql:/localhost:5432/instancedatabase.username=foodatabase.password=barsecret: foo

es sinónimo del siguiente archivo YAML:

database: url: jdbc:postgresql:/localhost:5432/instance username: foo password: barsecret: foo

También vale la pena mencionar que los archivos YAML no admiten la anotación @PropertySource, por lo que si necesitamos usar esta anotación, nos limitaría a usar una anotación archivo de propiedades.

otro punto notable es que en la versión 2.4.0 Spring Boot cambió la forma en que las propiedades se cargan desde archivos YAML de varios documentos., Anteriormente, el orden en el que se agregaban se basaba en el orden de activación del perfil. Con la nueva versión, sin embargo, el framework sigue las mismas reglas de orden que indicamos anteriormente .archivos de propiedades; las propiedades declaradas más bajas en el archivo simplemente anularán las más altas.

además, en esta versión los perfiles ya no se pueden activar desde documentos específicos del perfil, Lo que hace que el resultado sea más claro y predecible.

4.7. Importación de Archivos de Configuración Adicionales

Antes de la versión 2.4.,0, Se permite el arranque por resorte incluyendo archivos de configuración adicionales usando el resorte.config.ubicación y primavera.config.propiedades de ubicación adicional, pero tenían ciertas limitaciones. Por ejemplo, tenían que definirse antes de iniciar la aplicación (como propiedades del entorno o del sistema, o utilizando argumentos de línea de comandos), ya que se usaban al principio del proceso.

en la versión mencionada, podemos utilizar el resorte.config.importar propiedad dentro de la aplicación.propiedades o aplicación.archivo yml para incluir fácilmente archivos adicionales., Esta propiedad admite algunas características interesantes:

• agregar varios archivos o directorios
• Los archivos se pueden cargar desde el classpath o desde un directorio externo
• indicando si el proceso de inicio debe fallar si no se encuentra un archivo, o si es un archivo opcional
• importando archivos sin extensión

veamos un ejemplo válido:

Nota: aquí formateamos esta propiedad usando saltos de línea solo para mayor claridad.

Spring tratará las importaciones como un nuevo documento insertado inmediatamente debajo de la declaración de importación.

4.8., Propiedades de los argumentos de la línea de comandos

Además de usar archivos, podemos pasar propiedades directamente en la línea de comandos:

java -jar app.jar --property="value"

También podemos hacer esto a través de propiedades del sistema, que se proporcionan antes del comando-jar en lugar de después:

java -Dproperty.name="value" -jar app.jar

4.9. Propiedades de Variables de entorno

Spring Boot también detectará variables de entorno, tratándolas como propiedades:

export name=valuejava -jar app.jar

4.10., Aleatorización de valores de propiedades

Si no queremos valores de propiedades determinist, podemos usar RandomValuePropertySource para aleatorizar los valores de propiedades:

random.number=${random.int}random.long=${random.long}random.uuid=${random.uuid}

4.11. Tipos adicionales de fuentes de propiedades

Spring Boot admite una multitud de fuentes de propiedades, implementando un orden bien pensado para permitir la anulación sensible. Vale la pena consultar la documentación oficial, que va más allá del alcance de este artículo.,

Configuration Using Raw Beans-The PropertySourcesPlaceholderConfigurer

Además de los métodos convenientes para obtener propiedades en Spring, también podemos definir y regiter la propiedad configuration bean manualmente.

trabajar con PropertySourcesPlaceholderConfigurer nos da un control total sobre la configuración, con la desventaja de ser más detallado y la mayoría de las veces innecesario.,

veamos cómo podemos definir este bean usando la configuración de Java:

propiedades en contextos Padre-Hijo

esta pregunta surge una y otra vez: ¿qué sucede cuando nuestra aplicación web tiene un contexto padre y un contexto hijo? El contexto padre puede tener algunas funciones básicas comunes y beans, y luego uno (o varios) contextos hijos, tal vez conteniendo beans específicos de servlet.

en ese caso, ¿cuál es la mejor manera de definir archivos de propiedades e incluirlos en estos contextos? ¿Y cómo recuperar mejor estas propiedades de la primavera?

daremos un desglose simple.,

si el archivo está definido en el contexto Padre:

• @Value funciona en el contexto hijo: YES

• @Value funciona en el contexto Padre: YES

• environment.getProperty en contexto hijo: Yes

• environment.getProperty en el contexto Padre: yes

Si el archivo está definido en el contexto hijo:

• @Value funciona en el contexto hijo: YES

• @Value funciona en el contexto padre: no

• environment.getProperty en contexto hijo: Yes

• environment.,getProperty en el contexto padre: NO

conclusión

Este artículo mostró varios ejemplos de trabajo con propiedades y archivos de propiedades en primavera.

como siempre, todo el código que respalda el artículo está disponible en GitHub.