Si Spring Boot est exécuté dans le profil override , pouvons-nous avoir application-override.properties ayant des propriétés comme foo.baz qui ne sont pas définies dans application.properties? application.properties
spring.profiles.include=default foo.baz=1
application-override.properties
foo.bar=1
4 Réponses :
Vous pouvez créer une classe de configuration pour votre profil personnalisé et y charger le fichier de propriétés approprié comme ceci:
spring.profiles.active=override
De cette façon, toute la configuration que vous faites dans OverrideConfig (y compris la prise de propriétés de l'application -override.properties), ne se chargera que si le profil de remplacement est activé dans application.properties comme ceci:
@Configuration
@Profile("override")
@PropertySource("classpath:application-override.properties")
public class OverrideConfig {
}
Je ne suis pas convaincu d'utiliser @PropertySource selon la question. Cela peut être utile si vous souhaitez définir des conf / beans spécifiques en fonction de ce profil. Ce n'est pas le cas dans la question. Notez également que @PropertySource ("classpath: application-override.properties") n'est probablement pas nécessaire car le profil activé doit déjà rechercher application-override.properties dans le Emplacements.
C'est exact. Lorsque vous avez de nouvelles propriétés dans application-override.properties et que le profil de remplacement est le profil actif, alors oui dans votre programme les propriétés de application.properties ainsi que < code> application-override.properties est chargé.
L'utilisation de spring.profiles.include = default dans votre profil de remplacement n'est pas nécessaire.
En cas de chargement de plusieurs profils spécifiques avec les mêmes propriétés:
De plus, dans le contexte du remplacement de propriété avec des profils, il faut garder à l'esprit lorsque vous avez plusieurs profils actifs et qu'ils contiennent la même propriété. Le dernier profil de la liste sera utilisé.
Disons que vous démarrez votre programme avec mvn spring-boot: run -Drun.profiles = profile1, profile2
application-profile1.properties et application-profile2.properties
contient la propriété my.custom-property = x (pour profile1) et my.custom-property = y (pour profile2). La valeur de my.custom-property sera y , car c'était le dernier profil dans les profils fournis.
Pour faire court: Spring boot remplace les valeurs des propriétés portant le même nom selon leur ordre d'évaluation . Mais ici vous ne remplacez aucune propriété, vous en ajoutez une nouvelle.
C'est encore plus simple: Spring Boot l'ajoute simplement dans l'environnement Spring.
Exécutez simplement l'application en spécifiant ce profil et assurez-vous que les propriétés sont situées aux emplacements attendus par Spring Boot.
Exemple à partir d'un fat jar (propriété système Java):
mvn spring-boot:run -Dspring-boot.run.profiles=override
Exemple à partir du code source (propriété Maven):
java -Dspring.profiles.active=override -jar foo.jar
Le problème ci-dessus sera résolu en utilisant simplement l'annotation @profile , n'est-ce pas? il n'a pas besoin d'utiliser @PropertySource à moins que override.properties ne se trouve à un emplacement différent, n'est-ce pas?
@Deadpool Annotating @Profile ("override") fait charger la classe du bean lorsque le profil est activé au démarrage du conteneur. Mais pourquoi charger un bean spécifique pour activer un profil? Ce n'est pas l'exigence de l'OP ... Il n'a besoin ni de @PropertySource ni de @Profile , uniquement pour exécuter l'application en spécifiant le profil ( java -Dspring.profiles .active = override -jar foo.jar ) A propos de votre dernière remarque vous avez raison, cela peut être pour l'emplacement mais aussi le nom du fichier lui-même si ce n'est pas le défaut attendu.
Oui, vous pouvez le faire en ajoutant simplement le nom du profil à application.properties:
foo: bar: 1 --- spring: profiles: override foo: baz: 1 --- spring: profiles: otherOverride foo: bar: 2 baz: 2
Ensuite, vous pouvez charger le profil à partir de la ligne de commande:
java -jar foo.jar --spring.profiles=override
Spring chargera d'abord application.properties suivi de tout application- {profile} .properties .
Une autre option consiste à utiliser yaml et à tout charger dans un seul fichier:
application-override.properties