Spring Boot et plusieurs fichiers de configuration externes

Lors de l'utilisation de Spring Boot, les propriétés sont chargées dans l'ordre suivant (voir Configuration externalisée dans le guide de référence Spring Boot).

1. Arguments de ligne de commande.
2. Propriétés du système Java (Système.getProperties()).
3. Variables d'environnement du système d'exploitation.
4. JNDI attributs de java:comp/env
5. Une RandomValuePropertySource qui n'a que des propriétés dans random.*.
6. Propriétés d'application en dehors de votre pot emballé (application.y compris les variantes YAML et profile).
7. Propriétés de l'application emballées dans votre pot (application.y compris les variantes YAML et profile).
8. Annotations@PropertySource sur vos classes @Configuration.
9. Propriétés par défaut (spécifiées à l'aide de SpringApplication.setDefaultProperties).

Lors de la résolution des propriétés (c'est-à-dire @Value("${myprop}") la résolution se fait dans l'ordre inverse (donc en commençant par 9).

Pour ajouter différents fichiers vous pouvez utiliser les propriétés spring.config.location qui prennent une liste séparée par des virgules de fichiers de propriété ou d'emplacement de fichier (répertoires).

-Dspring.config.location=your/config/dir/

Celui ci-dessus ajoutera un répertoire qui sera consulté pour les fichiers application.properties.

-Dspring.config.location=classpath:job1.properties,classpath:job2.properties

Cela ajoutera le fichier de propriétés 2 aux fichiers chargés.

Les fichiers de configuration et les emplacements par défaut sont chargés avant les spring.config.location spécifiés de manière additionnelle, ce qui signifie que ces derniers remplaceront toujours les propriétés définies dans les propriétés précédentes. (Voir aussi cette section du Guide de référence de la botte à ressort).

Si spring.config.location contient des répertoires (par opposition aux fichiers), ils doivent se terminer par / (et seront ajoutés avec les noms générés à partir de spring.config.name avant d'être chargés). Le chemin de recherche par défaut classpath:,classpath:/config,file:,file:config/ est toujours utilisé, quelle que soit la valeur de spring.config.location. De cette façon, vous pouvez configurer des valeurs par défaut pour votre application dans application.properties (ou tout autre nom de base que vous choisissez avec spring.config.name) et le remplacer lors de l'exécution par un autre fichier, en gardant les valeurs par défaut.

Avec Spring boot , le ressort.config.l'emplacement fonctionne, il suffit de fournir des fichiers de propriétés séparés par des virgules.

Voir le code ci-dessous

@PropertySource(ignoreResourceNotFound=true,value="classpath:jdbc-${spring.profiles.active}.properties")
public class DBConfig{

     @Value("${jdbc.host}")
        private String jdbcHostName;
     }
}

On peut mettre la version par défaut de jdbc.propriétés à l'intérieur de l'application. Les versions externes peuvent être définies mensonge ceci.

java -jar target/myapp.jar --spring.config.location=classpath:file:///C:/Apps/springtest/jdbc.properties,classpath:file:///C:/Apps/springtest/jdbc-dev.properties

Basé sur la valeur de profil définie à l'aide de spring.profil.propriété active, la valeur de jdbc.l'hôte doit être ramassé. Alors quand (sous Windows)

set spring.profiles.active=dev

Jdbc.hôte prendra la valeur de jdbc-dev.propriété.

Pour

set spring.profiles.active=default

Jdbc.hôte prendra la valeur de jdbc.propriété.

Jetez un oeil à PropertyPlaceholderConfigurer, je trouve qu'il est plus clair à utiliser que l'annotation.

Par exemple

@Configuration
public class PropertiesConfiguration {


    @Bean
    public PropertyPlaceholderConfigurer properties() {
        final PropertyPlaceholderConfigurer ppc = new PropertyPlaceholderConfigurer();
//        ppc.setIgnoreUnresolvablePlaceholders(true);
        ppc.setIgnoreResourceNotFound(true);

        final List<Resource> resourceLst = new ArrayList<Resource>();

        resourceLst.add(new ClassPathResource("myapp_base.properties"));
        resourceLst.add(new FileSystemResource("/etc/myapp/overriding.propertie"));
        resourceLst.add(new ClassPathResource("myapp_test.properties"));
        resourceLst.add(new ClassPathResource("myapp_developer_overrides.properties")); // for Developer debugging.

        ppc.setLocations(resourceLst.toArray(new Resource[]{}));

        return ppc;
    }

Je viens d'avoir un problème similaire à cela et j'ai finalement compris la cause: l'application.le fichier de propriétés avait la mauvaise propriété et les attributs rwx. Donc, quand tomcat a démarré l'application.le fichier de propriétés était au bon endroit, mais appartenait à un autre utilisateur:

$ chmod 766 application.properties

$ chown tomcat application.properties

J'ai eu le même problème. Je voulais avoir la possibilité d'écraser un fichier de configuration interne au démarrage avec un fichier externe, similaire à l'application Spring Boot.détection des propriétés. Dans mon cas, c'est un utilisateur.fichier de propriétés où les utilisateurs de mes applications sont stockés.

Mes exigences:

Charger le fichier à partir des emplacements suivants (dans cet ordre)

1. Le chemin de classe
2. Un /config sous répertoire du répertoire courant.
3. Le courant répertoire
4. À partir d'un répertoire ou d'un emplacement de fichier donné par un paramètre de ligne de commande au démarrage

J'ai trouvé la solution suivante:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.PathResource;
import org.springframework.core.io.Resource;

import java.io.IOException;
import java.util.Properties;

import static java.util.Arrays.stream;

@Configuration
public class PropertiesConfig {

    private static final Logger LOG = LoggerFactory.getLogger(PropertiesConfig.class);

    private final static String PROPERTIES_FILENAME = "user.properties";

    @Value("${properties.location:}")
    private String propertiesLocation;

    @Bean
    Properties userProperties() throws IOException {
        final Resource[] possiblePropertiesResources = {
                new ClassPathResource(PROPERTIES_FILENAME),
                new PathResource("config/" + PROPERTIES_FILENAME),
                new PathResource(PROPERTIES_FILENAME),
                new PathResource(getCustomPath())
        };
        // Find the last existing properties location to emulate spring boot application.properties discovery
        final Resource propertiesResource = stream(possiblePropertiesResources)
                .filter(Resource::exists)
                .reduce((previous, current) -> current)
                .get();
        final Properties userProperties = new Properties();

        userProperties.load(propertiesResource.getInputStream());

        LOG.info("Using {} as user resource", propertiesResource);

        return userProperties;
    }

    private String getCustomPath() {
        return propertiesLocation.endsWith(".properties") ? propertiesLocation : propertiesLocation + PROPERTIES_FILENAME;
    }

}

Maintenant, l'application utilise la ressource classpath, mais vérifie également une ressource aux autres emplacements donnés. La dernière ressource qui existe sera choisie et utilisée. Je peux démarrer mon application avec java-jar myapp.jar --propriétés.lieu=/annuaire/myproperties.propriétés pour utiliser un emplacement de propriétés qui flotte mon bateau.

Un détail important ici: Utilisez une chaîne vide comme valeur par défaut pour les propriétés.emplacement dans l'annotation @ Value pour éviter les erreurs lorsque la propriété n'est pas définie.

La convention pour une propriété.l'emplacement est: Utilisez un répertoire ou un chemin d'accès à un fichier de propriétés en tant que propriétés.emplacement.

Si vous souhaitez remplacer uniquement des propriétés spécifiques, un PropertiesFactoryBean avec setIgnoreResourceNotFound(true) peut être utilisé avec le tableau de ressources défini comme emplacements.

Je suis assurez-vous que cette solution peut être étendue pour gérer plusieurs fichiers...

MODIFIER

Voici ma solution pour plusieurs fichiers :) Comme avant, cela peut être combiné avec un PropertiesFactoryBean.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.PathResource;
import org.springframework.core.io.Resource;

import java.io.IOException;
import java.util.Map;
import java.util.Properties;

import static java.util.Arrays.stream;
import static java.util.stream.Collectors.toMap;

@Configuration
class PropertiesConfig {

    private final static Logger LOG = LoggerFactory.getLogger(PropertiesConfig.class);
    private final static String[] PROPERTIES_FILENAMES = {"job1.properties", "job2.properties", "job3.properties"};

    @Value("${properties.location:}")
    private String propertiesLocation;

    @Bean
    Map<String, Properties> myProperties() {
        return stream(PROPERTIES_FILENAMES)
                .collect(toMap(filename -> filename, this::loadProperties));
    }

    private Properties loadProperties(final String filename) {
        final Resource[] possiblePropertiesResources = {
                new ClassPathResource(filename),
                new PathResource("config/" + filename),
                new PathResource(filename),
                new PathResource(getCustomPath(filename))
        };
        final Resource resource = stream(possiblePropertiesResources)
                .filter(Resource::exists)
                .reduce((previous, current) -> current)
                .get();
        final Properties properties = new Properties();

        try {
            properties.load(resource.getInputStream());
        } catch(final IOException exception) {
            throw new RuntimeException(exception);
        }

        LOG.info("Using {} as user resource", resource);

        return properties;
    }

    private String getCustomPath(final String filename) {
        return propertiesLocation.endsWith(".properties") ? propertiesLocation : propertiesLocation + filename;
    }

}

Il s'agit d'une approche simple utilisant spring boot

Classe de test.java

@Configuration
@Profile("one")
@PropertySource("file:/{selected location}/app.properties")
public class TestClass {

    @Autowired
    Environment env;

    @Bean
    public boolean test() {
        System.out.println(env.getProperty("test.one"));
        return true;
    }
}

L'application .propriétés contexte, dans votre emplacement sélectionné

test.one = 1234

Votre printemps de démarrage de l'application

@SpringBootApplication

public class TestApplication {

    public static void main(String[] args) {
        SpringApplication.run(testApplication.class, args);
    }
}

Et l'application prédéfinie .propriétés contexte

spring.profiles.active = one

Vous pouvez écrire autant de classes de configuration que vous le souhaitez et les activer/désactiver simplement en définissant spring.profil.active = le nom/les noms du profil {séparés par des virgules}

Comme vous pouvez le voir spring boot est génial, il suffit de se familiariser avec, il convient de mentionner que vous pouvez également utiliser @Value sur vos champs

@Value("${test.one}")
String str;

Spring boot nous permet d'écrire différents profils pour écrire pour différents environnements, par exemple, nous pouvons avoir des fichiers de propriétés séparés pour la production, l'assurance qualité et les environnements locaux

Application locale.le fichier de propriétés avec des configurations en fonction de ma machine locale est

spring.profiles.active=local

spring.data.mongodb.host=localhost
spring.data.mongodb.port=27017
spring.data.mongodb.database=users
spring.data.mongodb.username=humble_freak
spring.data.mongodb.password=freakone

spring.rabbitmq.host=localhost
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest
spring.rabbitmq.port=5672

rabbitmq.publish=true

De même, nous pouvons écrire application-prod.propriétés et application-qa.propriétés autant de fichiers de propriétés que nous voulons

Puis écrire quelques scripts pour démarrer l'application pour différents environnements, par exemple

mvn spring-boot:run -Drun.profiles=local
mvn spring-boot:run -Drun.profiles=qa
mvn spring-boot:run -Drun.profiles=prod

Botte à ressort 1.X et Spring Boot 2.X ne fournit pas les mêmes options et le même comportementExternalized Configuration.

La très bonne réponse de M. Deinum se réfère aux spécificités de Spring Boot 1.
Je vais mettre à jour pour Spring Boot 2 ici.

Propriétés de l'environnement sources et ordre

Spring Boot 2 utilise un ordre très particulier PropertySource conçu pour permettre un remplacement raisonnable des valeurs. Les propriétés sont considérées dans ce qui suit commande:

• Propriétés des paramètres globaux Devtools dans votre répertoire personnel (~/.printemps-boot-devtools.propriétés lorsque devtools est actif).

• @TestPropertySource annotations sur vos tests.

• @SpringBootTest#properties attribut d'annotation sur vos tests. Commande les arguments de la ligne.

• Propriétés de SPRING_APPLICATION_JSON (JSON intégré dans un variable d'environnement ou propriété système).

• ServletConfig init paramètre.

• ServletContext initialisation des paramètres.

• Attributs JNDI de java:comp/env.

• Propriétés du système Java (System.getProperties()).

• Variables d'environnement du système d'exploitation.

• Un RandomValuePropertySource, ce qui a des propriétés uniquement dans un ordre aléatoire.*.

• Propriétés d'application spécifiques au profil en dehors de votre pot emballé (application-{profile}.properties et variantes YAML).

• Propriétés d'application spécifiques au profil emballé dans votre pot (application-{profile}.properties et variantes YAML).

• Propriétés d'application en dehors de votre pot emballé (application.properties et variantes YAML).

• Propriétés d'application emballées dans votre pot (application.properties et variantes YAML).

• @PropertySource annotations sur votre @Configuration classes. Défaut propriétés (spécifiées par le paramètre SpringApplication.setDefaultProperties).

Pour spécifier des fichiers de propriétés externes, ces options devraient vous intéresser :

• Propriétés d'application spécifiques au profil en dehors de votre pot emballé (application-{profile}.properties et variantes YAML).

• Propriétés d'application en dehors de votre pot emballé (application.properties et variantes YAML).

• @PropertySource annotations sur votre @Configuration classes. Défaut propriétés (spécifiées par le paramètre SpringApplication.setDefaultProperties).

Vous ne pouvez utiliser qu'une seule de ces 3 options ou les combiner en fonction de votre exigence.
Par exemple, pour des cas très simples, utiliser uniquement des propriétés spécifiques au profil suffit, mais dans d'autres cas, vous pouvez utiliser à la fois des propriétés spécifiques au profil, des propriétés par défaut et @PropertySource.

Emplacements par défaut pour l'application.des fichiers de propriétés

A propos des fichiers application.properties (et variante), par défaut Spring les charge et ajoute leurs propriétés dans l'environnement à partir de ceux-ci dans l'ordre suivant :

• A / configuration sous-répertoire du répertoire courant

• Le répertoire courant

• Un paquet classpath /config

• Le chemin de La classe racine de

Les priorités supérieures sont si littéralement :
classpath:/,classpath:/config/,file:./,file:./config/.

Comment utiliser les fichiers de propriétés avec des noms spécifiques ?

Les emplacements par défaut ne sont pas toujours suffisants : les emplacements par défaut comme le nom de fichier par défaut (application.properties) peuvent ne pas convenir. Outre, comme dans la question OP, vous devrez peut-être spécifier plusieurs fichiers de configuration autres que application.properties (et variant).
Donc spring.config.name ne sera pas suffisant.

Dans ce cas, vous devez fournir un emplacement explicite en utilisant la propriété d'environnement spring.config.location (qui est une liste séparée par des virgules d'emplacements de répertoires ou de chemins de fichiers).
Pour être libre sur le modèle de noms de fichiers, privilégiez la liste des chemins de fichiers par rapport à la liste des répertoires.
Par exemple, faites comme ça:

java -jar myproject.jar --spring.config.location=classpath:/default.properties,classpath:/override.properties

De cette façon est le le plus verbeux est de simplement spécifier le dossier, mais c'est aussi le moyen de spécifier très finement nos fichiers de configuration et de documenter clairement les propriétés efficacement utilisées.

Printemps.config.l'emplacement remplace maintenant les emplacements par défaut au lieu de les ajouter

Avec Spring Boot 1, l'argument spring.config.location ajoute des emplacements spécifiés dans l'environnement Spring.
Mais à partir de Spring Boot 2, spring.config.location remplace les emplacements par défaut utilisés par Spring par les emplacements spécifiés dans l'environnement printanier comme indiqué dans la documentation.

Lorsque les emplacements de configuration personnalisés sont configurés en utilisant spring.config.location, ils remplacent les emplacements par défaut. Pour exemple, si spring.config.location est configuré avec la valeur classpath:/custom-config/,file:./custom-config/, l'ordre de recherche devient le suivant:

1. file:./custom-config/

2. classpath:custom-config/

spring.config.location est maintenant un moyen de faire en sorte que tout application.properties fichier doit être explicitement défini.
Pour les pots uber qui ne sont pas censés emballer des fichiers application.properties, c'est plutôt bien.

Pour conserver l'ancien comportement de spring.config.location lors de l'utilisation de Spring Boot 2, vous pouvez utiliser la nouvelle propriété spring.config.additional-location au lieu de spring.config.location qui ajoute toujours les emplacements comme indiqué par la documentation:

Alternativement, lorsque des emplacements de configuration personnalisés sont configurés en utilisant spring.config.additional-location, ils sont utilisés en plus de la emplacements par défaut.

Dans la pratique,

Supposons donc que, comme dans la question OP, vous avez 2 fichiers de propriétés externes à spécifier et 1 fichier de propriétés inclus dans le pot uber.

Pour utiliser uniquement les fichiers de configuration que vous avez spécifiés:

-Dspring.config.location=classpath:/job1.properties,classpath:/job2.properties,classpath:/applications.properties   

Pour ajouter des fichiers de configuration aux emplacements par défaut:

-Dspring.config.additional-location=classpath:/job1.properties,classpath:/job2.properties

classpath:/applications.properties est dans le dernier exemple non requis car les emplacements par défaut ont cela et que les emplacements par défaut ne sont pas ici écrasé mais étendu.

J'ai trouvé que c'était un modèle utile à suivre:

@RunWith(SpringRunner)
@SpringBootTest(classes = [ TestConfiguration, MyApplication ],
        properties = [
                "spring.config.name=application-MyTest_LowerImportance,application-MyTest_MostImportant"
                ,"debug=true", "trace=true"
        ]
)

Ici, nous remplaçons l'utilisation de "application.yml "à utiliser" application-MyTest_LowerImportance.yml "et aussi" application-MyTest_MostImportant.yml "
(Le printemps cherchera également .fichiers de propriétés)

Également inclus comme un bonus supplémentaire sont les paramètres de débogage et de trace, sur une ligne séparée afin que vous puissiez les commenter si nécessaire ;]

Le debug / trace est incroyablement utile car Spring videra les noms de tous les fichiers qu'il charge et ceux qu'il essaie de charger.
Vous verrez des lignes comme celle-ci dans la console au moment de l'exécution:

TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_MostImportant.properties' (file:./config/application-MyTest_MostImportant.properties) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_MostImportant.xml' (file:./config/application-MyTest_MostImportant.xml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_MostImportant.yml' (file:./config/application-MyTest_MostImportant.yml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_MostImportant.yaml' (file:./config/application-MyTest_MostImportant.yaml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_LowerImportance.properties' (file:./config/application-MyTest_LowerImportance.properties) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_LowerImportance.xml' (file:./config/application-MyTest_LowerImportance.xml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_LowerImportance.yml' (file:./config/application-MyTest_LowerImportance.yml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_LowerImportance.yaml' (file:./config/application-MyTest_LowerImportance.yaml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_MostImportant.properties' (file:./application-MyTest_MostImportant.properties) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_MostImportant.xml' (file:./application-MyTest_MostImportant.xml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_MostImportant.yml' (file:./application-MyTest_MostImportant.yml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_MostImportant.yaml' (file:./application-MyTest_MostImportant.yaml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_LowerImportance.properties' (file:./application-MyTest_LowerImportance.properties) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_LowerImportance.xml' (file:./application-MyTest_LowerImportance.xml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_LowerImportance.yml' (file:./application-MyTest_LowerImportance.yml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./application-MyTest_LowerImportance.yaml' (file:./application-MyTest_LowerImportance.yaml) resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_MostImportant.properties' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_MostImportant.xml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_MostImportant.yml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_MostImportant.yaml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_LowerImportance.properties' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_LowerImportance.xml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_LowerImportance.yml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/config/application-MyTest_LowerImportance.yaml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/application-MyTest_MostImportant.properties' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/application-MyTest_MostImportant.xml' resource not found
DEBUG 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Loaded config file 'file:/Users/xxx/dev/myproject/target/test-classes/application-MyTest_MostImportant.yml' (classpath:/application-MyTest_MostImportant.yml)
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/application-MyTest_MostImportant.yaml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/application-MyTest_LowerImportance.properties' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/application-MyTest_LowerImportance.xml' resource not found
DEBUG 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Loaded config file 'file:/Users/xxx/dev/myproject/target/test-classes/application-MyTest_LowerImportance.yml' (classpath:/application-MyTest_LowerImportance.yml)
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'classpath:/application-MyTest_LowerImportance.yaml' resource not found
TRACE 93941 --- [   main] o.s.b.c.c.ConfigFileApplicationListener  : Skipped config file 'file:./config/application-MyTest_MostImportant-test.properties' (file:./config/application-MyTest_MostImportant-test.properties) resource not found

Une version modifiée de la solution @mxsb qui nous permet de définir plusieurs fichiers et dans mon cas, ce sont des fichiers yml.

Dans mon application-dev.yml, j'ai ajouté cette configuration qui me permet d'injecter tous les yml qui ont-dev.yml en eux. Cela peut également être une liste de fichiers spécifiques. "classpath:/test/test.yml, classpath: / test2 / test.yml "

application:
  properties:
    locations: "classpath*:/**/*-dev.yml"

Cela permet d'obtenir une carte de propriétés.

@Configuration

public class PropertiesConfig {

private final static Logger LOG = LoggerFactory.getLogger(PropertiesConfig.class);

@Value("${application.properties.locations}")
private String[] locations;

@Autowired
private ResourceLoader rl;

@Bean
Map<String, Properties> myProperties() {
    return stream(locations)
            .collect(toMap(filename -> filename, this::loadProperties));
}

private Properties loadProperties(final String filename) {

    YamlPropertySourceLoader loader = new YamlPropertySourceLoader();
    try {
        final Resource[] possiblePropertiesResources = ResourcePatternUtils.getResourcePatternResolver(rl).getResources(filename);
        final Properties properties = new Properties();
        stream(possiblePropertiesResources)
                .filter(Resource::exists)
                .map(resource1 -> {
                    try {
                        return loader.load(resource1.getFilename(), resource1);
                    } catch (IOException e) {
                        throw new RuntimeException(e);
                    }
                }).flatMap(l -> l.stream())
                .forEach(propertySource -> {
                    Map source = ((MapPropertySource) propertySource).getSource();
                    properties.putAll(source);
                });

        return properties;
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}
}

Cependant, si comme dans mon cas, je voulais avoir à diviser les fichiers yml pour chaque profil et chargez-les et injectez-les directement dans la configuration spring avant l'initialisation des beans.

config
    - application.yml
    - application-dev.yml
    - application-prod.yml
management
    - management-dev.yml
    - management-prod.yml

... vous avez l'idée

Le composant est légèrement différent

@Component
public class PropertiesConfigurer extends     PropertySourcesPlaceholderConfigurer
    implements EnvironmentAware, InitializingBean {

private final static Logger LOG = LoggerFactory.getLogger(PropertiesConfigurer.class);

private String[] locations;

@Autowired
private ResourceLoader rl;
private Environment environment;

@Override
public void setEnvironment(Environment environment) {
    // save off Environment for later use
    this.environment = environment;
    super.setEnvironment(environment);
}

@Override
public void afterPropertiesSet() throws Exception {
    // Copy property sources to Environment
    MutablePropertySources envPropSources = ((ConfigurableEnvironment) environment).getPropertySources();
    envPropSources.forEach(propertySource -> {
        if (propertySource.containsProperty("application.properties.locations")) {
            locations = ((String) propertySource.getProperty("application.properties.locations")).split(",");
            stream(locations).forEach(filename -> loadProperties(filename).forEach(source ->{
                envPropSources.addFirst(source);
            }));
        }
    });
}


private List<PropertySource> loadProperties(final String filename) {
    YamlPropertySourceLoader loader = new YamlPropertySourceLoader();
    try {
        final Resource[] possiblePropertiesResources = ResourcePatternUtils.getResourcePatternResolver(rl).getResources(filename);
        final Properties properties = new Properties();
        return stream(possiblePropertiesResources)
                .filter(Resource::exists)
                .map(resource1 -> {
                    try {
                        return loader.load(resource1.getFilename(), resource1);
                    } catch (IOException e) {
                        throw new RuntimeException(e);
                    }
                }).flatMap(l -> l.stream())
                .collect(Collectors.toList());
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

}

"Type de services.msc " dans la fenêtre contextuelle d'exécution (windows + R). Cela affichera tous les services en cours d'exécution Sélectionnez le service Postgres dans la liste et cliquez sur démarrer/arrêter/redémarrer.

J'ai rencontré beaucoup de problèmes en essayant de comprendre cela. Voici ma configuration,

Dev Env: Windows 10, Java : 1.8.0_25, Botte de ressort: 2.0.3.PUBLIER, Printemps : 5.0.7.VERSION

Ce que j'ai trouvé, c'est que spring s'en tient au concept "Valeurs par défaut sensibles pour la configuration". Ce que cela se traduit par, vous devez avoir tous vos fichiers de propriété dans le cadre de votre fichier war. Une fois là-bas, vous pouvez ensuite les remplacer en utilisant le "spring spring.config.supplémentaire-emplacement" propriété de ligne de commande pour pointer vers des fichiers de propriétés externes. Mais cela ne fonctionnera PAS si les fichiers de propriété ne font pas partie du fichier war d'origine.

Code de démonstration: https://github.com/gselvara/spring-boot-property-demo/tree/master