/{application}/{profile}[/{label}]
+/{application}/{profile}[/{label}]
+/{application}-{profile}.yml
+/{label}/{application}-{profile}.yml
+/{application}-{profile}.properties
+/{label}/{application}-{profile}.properties
/{application}/{profile}[/{label}]
+/{application}/{profile}[/{label}]
+/{application}-{profile}.yml
+/{label}/{application}-{profile}.yml
+/{application}-{profile}.properties
+/{label}/{application}-{profile}.properties
SpringApplication (i.e. what is normally "application" in a regular
Spring Boot app), "profile" is an active profile (or comma-separated
list of properties), and "label" is an optional git label (defaults to
-"master").
+"master".) The YAML and properties forms are coalesced into a single
+map, even if the origin of the values (reflected in the
+"propertySources" of the "standard" form) has multiple sources.
Environment.
The Config Service serves property sources from /{name}/{env}/{label}, where the default bindings are
"name" = ${spring.application.name}
"env" = ${spring.profiles.active} (actually Environment.getActiveProfiles())
"label" = "master"
+All of them can be overridden by setting spring.cloud.config.*
+(where * is "name", "env" or "label"). The "label" is useful for
+rolling back to previous versions of configuration; with the default
+Config Server implementation it can be a git label, branch name or
+commit id.
The Config Client operates by creating a "bootstrap" application @@ -978,9 +1013,9 @@ nicely separate. Example:
It is a good idea to set the spring.application.name in
-bootstrap.yml if your application needs any application-specific
-configuration from the server.
It is a good idea to set the spring.application.name (in
+bootstrap.yml or application.yml) if your application needs any
+application-specific configuration from the server.
You can disable the bootstrap process completely by setting @@ -988,7 +1023,79 @@ configuration from the server.
If you build an application context from SpringApplication or
+SpringApplicationBuilder, then the Bootstrap context is added as a
+parent to that context. It is a feature of Spring that child contexts
+inherit property sources and profiles from their parent, so the "main"
+application context will contain additional property sources, compared
+to building the same context without Spring Cloud Config. The
+additional property sources are:
"bootstrap": an optional CompositePropertySource appears with high
+priority if any PropertySourceLocators are found in the Bootstrap
+context, and they have non-empty properties. An example would be
+properties from the Spring Cloud Config Server. See
+below for instructions
+on how to customize the contents of this property source.
"applicationConfig: [classpath:bootstrap.yml]" (and friends if
+Spring profiles are active). If you have a bootstrap.yml (or
+properties) then those properties are used to configure the Bootstrap
+context, and then they get added to the child context when its parent
+is set. They have lower precedence than the application.yml (or
+properties) and any other property sources that are added to the child
+as a normal part of the process of creating a Spring Boot
+application. See below for
+instructions on how to customize the contents of these property
+sources.
Because of the ordering rules of property sources the "bootstrap"
+entries take precedence, but note that these do not contain any data
+from bootstrap.yml, which has very low precedence, but can be used
+to set defaults.
You can extend the context hierarchy by simply setting the parent
+context of any ApplicationContext you create, e.g. using its own
+interface, or with the SpringApplicationBuilder convenience methods
+(parent(), child() and sibling()). Note that the
+SpringApplicationBuilder allows you to share an Environment
+amongst the whole hierarchy, but that is not the default. Thus,
+normally you expect to see differences between different levels in the
+hierarchy, and sibling contexts in particular do not need to have the
+same profiles or property sources, even though they will share common
+things with their parent. Every context in the hierarchy will have its
+own "bootstrap" property source (possibly empty) to avoid promoting
+values inadvertently from parents down to their descendants.
The bootstrap.yml (or .properties) location can be specified using
+`spring.cloud.bootstrap.name (default "bootstrap") or
+spring.cloud.bootstrap.location (default empty), e.g. in System
+properties. Those properties behave like the spring.config.*
+variants with the same name, 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) then properties in that profile will be
+loaded as well, just like in a regular Spring Boot app, e.g. from
+bootstrap-development.properties for a "development" profile.
The bootstrap context can be trained to do anything you like by adding
entries to /META-INF/spring.factories under the key
@@ -1010,7 +1117,7 @@ classes found in spring.factories and then all @Beans
The default property source for external configuration added by the bootstrap process is the Config Server, but you can add additional @@ -1111,7 +1218,7 @@ grabbing it in the bootstrap context and injecting one).