Spring Boot et plusieurs fichiers de configuration externes

Question

J'ai plusieurs fichiers de propriétés que je veux charger depuis classpath. Il existe un paramètre par défaut sous /src/main/resources qui fait partie de myapp.jar. Ma springcontext s'attend à ce que les fichiers se trouvent sur le chemin de classe. c'est à dire. 

<util:properties id="Job1Props"
    location="classpath:job1.properties"></util:properties>

<util:properties id="Job2Props"
    location="classpath:job2.properties"></util:properties>

J'ai également besoin de l'option pour remplacer ces propriétés par un ensemble externe. J'ai un dossier de configuration externe dans cwd. Selon Spring Boot, le dossier de configuration de la doc doit être sur classpath. Mais doc ne précise pas si elle ne fera que remplacer le applicaiton.properties à partir de là ou toutes les propriétés de config. 

Lorsque je l'ai testé, seul application.properties est récupéré et le reste des propriétés est toujours extrait de /src/main/resources. J'ai essayé de les fournir sous forme de liste séparée par des virgules à spring.config.location, mais le jeu par défaut n'est toujours pas remplacé.

Comment faire en sorte que plusieurs fichiers de configuration externes remplacent ceux par défaut? 

En guise de solution de contournement, j’utilise actuellement app.config.location (propriété spécifique à l’application) que je fournis via la ligne de commande. c'est à dire 

Java -jar myapp.jar app.config.location=file:./config

et j'ai changé ma applicationcontext en 

<util:properties id="Job2Props"
    location="{app.config.location}/job2.properties"></util:properties>

Et voici comment je fais la séparation entre fichier et classpath lors du chargement de l'application. 
EDITS:

//psuedo code

if (StringUtils.isBlank(app.config.location)) {
            System.setProperty(APP_CONFIG_LOCATION, "classpath:");
}

J'aimerais vraiment ne pas utiliser la solution de contournement ci-dessus et que Spring remplace tous les fichiers de configuration externes sur le chemin d'accès aux classes, comme c'est le cas pour le fichier application.properties.

Answer 1

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

1. Arguments en ligne de commande.
2. Propriétés système Java (System.getProperties ()).
3. Variables d'environnement de système d'exploitation.
4. Attributs JNDI à partir de Java: comp/env
5. RandomValuePropertySource qui n'a que des propriétés dans random. *.
6. Propriétés d'application en dehors de votre fichier jar packagé (application.properties, y compris YAML et variantes de profil).
7. Propriétés d'application contenues dans votre fichier jar (application.properties, y compris YAML et variantes de profil).
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 est effectuée dans l'ordre inverse (à partir de 9).

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

-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 les 2 fichiers de propriétés aux fichiers chargés. 

Les fichiers de configuration et les emplacements par défaut sont chargés avant ceux de spring.config.location spécifiés par addition, ce qui signifie que ces derniers remplaceront toujours les propriétés définies dans les précédents. (Voir aussi cette section du Guide de référence de Spring Boot).

Si spring.config.location contient des répertoires (par opposition aux fichiers), ils doivent se terminer par/(et seront ajoutés aux 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 manière, vous pouvez définir les valeurs par défaut de votre application dans application.properties (ou tout autre nom de base choisi avec spring.config.name) et le remplacer au moment de l'exécution par un autre fichier, en conservant les valeurs par défaut.

UPDATE: En tant que comportement de spring.config.location remplace maintenant la valeur par défaut au lieu d’ajouter. Vous devez utiliser spring.config.additional-location pour conserver les valeurs par défaut. Ceci est un changement de comportement de 1.x à 2.x

Answer 2

Avec Spring boot, le fichier spring.config.location 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.properties dans l'application. Les versions externes peuvent être définies comme cela.

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

En fonction de la valeur de profil définie à l'aide de la propriété spring.profiles.active, la valeur de jdbc.Host sera extraite ..__

set spring.profiles.active=dev

jdbc.Host prendra la valeur de jdbc-dev.properties.

pour 

set spring.profiles.active=default

jdbc.Host prendra la valeur de jdbc.properties.

Answer 3

Jetez un coup d'oeil au PropertyPlaceholderConfigurer, je le trouve 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;
    }

Answer 4

Spring Boot 1.X et Spring Boot 2.X ne fournissent pas les mêmes options et le même comportement à propos du Externalized Configuration . 

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

Sources de propriétés d'environnement et ordre 

Spring Boot 2 utilise un ordre PropertySource très particulier conçu pour permettre un dépassement raisonnable des valeurs. Les propriétés sont considérées dans l'ordre suivant:

• Propriétés de paramètres globaux Devtools sur votre répertoire de base (~/.spring-boot-devtools.properties lorsque devtools est actif).

• @TestPropertySource annotations sur vos tests.

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

• Propriétés de SPRING_APPLICATION_JSON (JSON intégré incorporé dans une variable d’environnement ou une propriété système .__).

• ServletConfig paramètres init.

• ServletContext paramètres init.

• Attributs JNDI à partir de Java:comp/env.

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

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

• RandomValuePropertySource qui n'a des propriétés que de manière aléatoire. *.

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

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

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

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

• Annotations @PropertySource sur vos classes @Configuration. 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 fichier jar emballé (variantes application-{profile}.properties et YAML).

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

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

Vous pouvez utiliser une seule de ces 3 options ou les combiner selon vos besoins.
Par exemple, dans des cas très simples, l’utilisation de propriétés spécifiques à un profil suffit, mais dans d’autres cas, vous pouvez utiliser à la fois les propriétés spécifiques au profil, les propriétés par défaut et @PropertySource. 

Emplacements par défaut des fichiers application.properties 

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

• Un sous-répertoire/config du répertoire en cours

• Le répertoire courant

• Un paquet classpath/config

• La racine du classpath

Les priorités les plus élevées sont 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 tels que le nom de fichier par défaut (application.properties) peuvent ne pas convenir. En outre, comme dans la question OP, vous devrez peut-être spécifier plusieurs fichiers de configuration autres que application.properties (et sa variante).
Donc, spring.config.name ne suffira pas. 

Dans ce cas, vous devez fournir un emplacement explicite à l'aide de la propriété d'environnement spring.config.location (qui est une liste d'emplacement de répertoire ou de chemin de fichier séparés par des virgules).
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

C’est ainsi que c’est le plus détaillé qui ne fait que 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 effectivement utilisées. 

spring.config.location remplace maintenant les emplacements par défaut au lieu de leur ajouter 

Avec Spring Boot 1, l'argument spring.config.location ajoute les 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 Spring, comme indiqué par dans la documentation . 

Lorsque les emplacements de configuration personnalisés sont configurés à l'aide de spring.config.location, ils remplacent les emplacements par défaut. Pour Par 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 s'assurer que tout fichier application.properties doit être spécifié explicitement.
Pour les JARs multiples qui ne sont pas supposés empaqueter les fichiers application.properties, il s'agit plutôt de Nice. 

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 les emplacements comme indiqué dans la documentation : 

Sinon, lorsque les emplacements de configuration personnalisés sont configurés à l'aide de spring.config.additional-location, ils sont utilisés en plus du emplacements par défaut. 

---

En pratique 

En supposant que, comme dans la question OP, vous disposiez de 2 fichiers de propriétés externes à spécifier et d'un fichier de propriétés inclus dans le fichier jar. 

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 à ceux-ci 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 écrasés mais étendus.

Answer 5

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

Mes exigences:

Chargez le fichier depuis les emplacements suivants (dans cet ordre)

1. Le classpath
2. Un sous-répertoire / config du répertoire en cours. 
3. Le répertoire courant
4. Depuis un répertoire ou un emplacement de fichier donné par un paramètre de ligne de commande au démarrage

Je suis venu avec 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 recherche également une ressource aux autres emplacements donnés. La dernière ressource existante sera sélectionnée et utilisée . Je peux démarrer mon application avec Java -jar myapp.jar --properties.location =/directory/myproperties.properties pour utiliser un emplacement de propriétés qui flotte dans mon bateau. .

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

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

Si vous souhaitez remplacer uniquement des propriétés spécifiques, un objet PropertiesFactoryBean avec setIgnoreResourceNotFound (true) peut être utilisé avec le tableau de ressources défini en tant qu'emplacement.

Je suis sûr 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;
    }

}

Answer 6

spring Boot nous permet d'écrire différents profils à écrire pour différents environnements. Par exemple, nous pouvons avoir des fichiers de propriétés séparés pour les environnements de production, qa et locaux

fichier application-local.properties avec les configurations correspondant à ma machine locale

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.properties et application-qa.properties autant de fichiers de propriétés que nous le souhaitons.

écrivez ensuite des scripts pour démarrer l’application dans 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

Answer 7

ceci est une approche simple en utilisant une botte à ressort

TestClass.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;
    }
}

le app.properties contexte, dans votre emplacement sélectionné

test.one = 1234

votre application de démarrage de printemps  

@SpringBootApplication

public class TestApplication {

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

et le prédéfini application.properties context

spring.profiles.active = one

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

comme vous pouvez voir que Spring Boot est formidable, il faut parfois s'y familiariser, il est bon de noter que vous pouvez aussi utiliser @Value dans vos champs.

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

Answer 8

Je viens d'avoir un problème similaire à celui-ci et j'ai finalement trouvé la cause: le fichier application.properties avait la propriété et les attributs rwx incorrects. Ainsi, lorsque Tomcat a démarré, le fichier application.properties se trouvait au bon emplacement, mais appartenait à un autre utilisateur:

$ chmod 766 application.properties

$ chown Tomcat application.properties

Answer 9

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 contenant -dev.yml. Cela peut être aussi une liste de fichiers spécifiques . "Classpath: /test/test.yml,classpath: /test2/test.yml"

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

Cela aide à obtenir une carte des 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 souhaitais fractionner des fichiers yml pour chaque profil, les charger et les injecter directement dans la configuration du ressort avant l’initialisation des beans. 

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

... vous avez eu 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);
    }
}

}

Answer 10

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" par "application-MyTest_LowerImportance.yml" et "application-MyTest_MostImportant.yml".
(Spring recherchera également les fichiers .properties) 

Les paramètres de débogage et de trace sont également inclus en tant que bonus supplémentaire sur une ligne distincte afin que vous puissiez les commenter si nécessaire;] 

Les procédures de débogage/trace sont incroyablement utiles car Spring dumpe 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 lors 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

Answer 11

Si vous souhaitez remplacer les valeurs spécifiées dans votre fichier application.properties, vous pouvez modifier votre profil actif pendant que vous exécutez votre application et créez un fichier de propriétés d'application pour le profil. Ainsi, par exemple, spécifions le profil actif "override" puis, en supposant que vous ayez créé votre nouveau fichier de propriétés d'application appelé "application-override.properties" sous/tmp, vous pourrez alors exécuter

Java -jar yourApp.jar --spring.profiles.active="override" --spring.config.location="file:/tmp/,classpath:/" 

Les valeurs spécifiées sous spring.config.location sont évaluées dans l’ordre inverse. Ainsi, dans mon exemple, le classpat est évalué en premier, puis la valeur du fichier.

Si le fichier jar et le fichier "application-override.properties" se trouvent dans le répertoire en cours, vous pouvez simplement utiliser

Java -jar yourApp.jar --spring.profiles.active="override"

depuis que Spring Boot trouvera le fichier de propriétés pour vous