From 32f2a807a1b91f60dd42ec0c37717902cd5bcc70 Mon Sep 17 00:00:00 2001
From: buildmaster spring.config.* va
In fact, they are used to set up the bootstrap ApplicationContext by setting those properties in its Environment.
If there is an active profile (from spring.profiles.active or through the Environment API in the
context you are building), properties in that profile get loaded as well, the same as in a regular Spring Boot app — for example, from bootstrap-development.properties for a development profile.
The property sources that are added to your application by the bootstrap context are often “remote” (from example, from Spring Cloud Config Server).
-By default, they cannot be overridden locally, except on the command line.
+By default, they cannot be overridden locally.
If you want to let your applications override the remote properties with their own System properties or config files, the remote property source has to grant it permission by setting spring.cloud.config.allowOverride=true (it does not work to set this locally).
-Once that flag is set, two finer-grained settings control the location of the remote properties in relation to system properties and the application’s local configuration:
spring.cloud.config.overrideNone=true: Override from any local property source.spring.cloud.config.overrideSystemProperties=false: Only system properties and environment variables (but not the local config files) should override the remote settings.The bootstrap context can be set to do anything you like by adding entries to /META-INF/spring.factories under a key named org.springframework.cloud.bootstrap.BootstrapConfiguration.
+Once that flag is set, two finer-grained settings control the location of the remote properties in relation to system properties and the application’s local configuration:
spring.cloud.config.overrideNone=true: Override from any local property source.spring.cloud.config.overrideSystemProperties=false: Only system properties, command line arguments, and environment variables (but not the local config files) should override the remote settings.The bootstrap context can be set to do anything you like by adding entries to /META-INF/spring.factories under a key named org.springframework.cloud.bootstrap.BootstrapConfiguration.
This holds a comma-separated list of Spring @Configuration classes that are used to create the context.
Any beans that you want to be available to the main application context for autowiring can be created here.
There is a special contract for @Beans of type ApplicationContextInitializer.
diff --git a/single/spring-cloud-commons.html b/single/spring-cloud-commons.html
index 88eedd0f..2dd3f1ea 100644
--- a/single/spring-cloud-commons.html
+++ b/single/spring-cloud-commons.html
@@ -41,9 +41,9 @@ Those properties behave like the spring.config.* va
In fact, they are used to set up the bootstrap ApplicationContext by setting those properties in its Environment.
If there is an active profile (from spring.profiles.active or through the Environment API in the
context you are building), properties in that profile get loaded as well, the same as in a regular Spring Boot app — for example, from bootstrap-development.properties for a development profile.
The property sources that are added to your application by the bootstrap context are often “remote” (from example, from Spring Cloud Config Server).
-By default, they cannot be overridden locally, except on the command line.
+By default, they cannot be overridden locally.
If you want to let your applications override the remote properties with their own System properties or config files, the remote property source has to grant it permission by setting spring.cloud.config.allowOverride=true (it does not work to set this locally).
-Once that flag is set, two finer-grained settings control the location of the remote properties in relation to system properties and the application’s local configuration:
spring.cloud.config.overrideNone=true: Override from any local property source.spring.cloud.config.overrideSystemProperties=false: Only system properties and environment variables (but not the local config files) should override the remote settings.The bootstrap context can be set to do anything you like by adding entries to /META-INF/spring.factories under a key named org.springframework.cloud.bootstrap.BootstrapConfiguration.
+Once that flag is set, two finer-grained settings control the location of the remote properties in relation to system properties and the application’s local configuration:
spring.cloud.config.overrideNone=true: Override from any local property source.spring.cloud.config.overrideSystemProperties=false: Only system properties, command line arguments, and environment variables (but not the local config files) should override the remote settings.The bootstrap context can be set to do anything you like by adding entries to /META-INF/spring.factories under a key named org.springframework.cloud.bootstrap.BootstrapConfiguration.
This holds a comma-separated list of Spring @Configuration classes that are used to create the context.
Any beans that you want to be available to the main application context for autowiring can be created here.
There is a special contract for @Beans of type ApplicationContextInitializer.
diff --git a/spring-cloud-commons.xml b/spring-cloud-commons.xml
index 8c34bdd2..68768e7c 100644
--- a/spring-cloud-commons.xml
+++ b/spring-cloud-commons.xml
@@ -103,7 +103,7 @@ context you are building), properties in that profile get loaded as well, the sa