En caso de que su procesamiento de configuración haya cambiado de forma incompatible y desee utilizar el modo de procesamiento "heredado", puede volver a habilitarlo configurando:

 spring.config.use-legacy-processing=true

o alternativamente, usando YAML:

 spring: config: use-legacy-processing: true

que debería revertir el procesamiento de configuración al equivalente 2.3.x Tenga en cuenta, sin embargo, que esta propiedad existe únicamente para facilitar la migración de configuraciones de perfil de 2.3.x a 2.4.x y probablemente quedará obsoleta y se eliminará en una versión principal futura ¹ , por lo que aún debe intentar migrar lo antes posible. Para entender el motivo de este cambio y alguna información adicional, sigue leyendo.

Cabe destacar en 2.4.0 los siguientes dos paradigmas:

Entonces, en Spring Boot 2.4, planeamos realizar dos cambios significativos en la forma en que se cargan las propiedades y los archivos YAML:

1. Los documentos se cargarán en el orden en que están definidos.

2. Los perfiles ya no se pueden activar desde documentos específicos del perfil.

De hecho, este cambio ha hecho que la lógica de qué anula qué cuándo sea considerablemente más simple de digerir, pero lleva a tener que deshabilitar algunas funciones. Por ejemplo:

 my.prop: test --- spring.profiles: prodprops my.prop: prod --- spring.profiles: prod # no longer works - activating a profile from a profile-specific document! spring.profiles.include: prodprops

daría lugar a una excepción ya que la configuración intenta activar un perfil desde un documento específico del perfil, lo que ya no está permitido.

Para cubrir este caso de uso (y otros), se agregaron grupos de perfiles como una función. Esto significa que para habilitar su comportamiento anterior, necesitaría crear un grupo de perfil de la siguiente manera:

 spring.profiles.group.<group>=dev, auth

o alternativamente, en YAML:

 spring: profiles: group: <group>: dev, auth

Donde <group> es el nombre del grupo de perfiles elegido. Tenga en cuenta que puede definir varios grupos, todos los cuales deben tener nombres diferentes. Si luego inicia su aplicación usando el perfil <group> , todos los perfiles que forman parte de ese grupo deberían estar activados.

Como nota al margen, Spring Boot 2.4.0 también agregó soporte para archivos de propiedades de varios documentos, que tienen el siguiente aspecto:

 test=value spring.profiles.active=local #--- spring.config.activate.on-profile=dev test=overridden value

Tenga en cuenta el separador de documentos ( #--- ). Esto le permite tener una lógica de anulación similar en los archivos .properties como en los archivos .yml .

Nuevamente, esta y otra información se proporciona en la publicación de actualización correspondiente.

¹ Si las obsolescencias anteriores son un indicador, la propiedad debe eliminarse en 2.5.0 como mínimo o en 2.6.0 como máximo, siendo lo último más probable (y una obsolescencia a partir de 2.5.x ).

Puede usar spring.config.import usando classpath:

 spring.config.import=classpath:application-DEV.yml,classpath:application-auth.yml

Aunque tenemos una respuesta aceptada arriba. Pero compartiría mi solución a través de varios archivos. Tengo varios archivos de configuración en mi proyecto

 ./ application.yml application-auth.yml application-mockauth.yml application-datasource.yml

El cuerpo de application-auth.yml o application-datasource.yml es el mismo que estamos implementando antes de Spring Boot 2.4. El ajuste menor se ubicará dentro de application.yml

 spring: profiles: group: "dev": "datasource,mockauth" "prod": "datasource,auth"

En lugar de spring.profiles.include, agrupará la configuración relacionada con el nombre del entorno (dev, prod...).