SpringCloud/spring-cloud-config
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

More detail on context hierarchies

Browse Source
This commit is contained in:
Dave Syer
2014-10-31 08:54:55 +00:00
parent 9efae007fa
commit ccf4da59c2
1 changed files with 20 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
docs/src/main/asciidoc/spring-cloud-config.adoc
View File

@@ -267,7 +267,8 @@ For a Spring Boot Actuator application there are some additional management endp
=== Locating Remote Configuration Resources
The Config Service serves property sources from `/{name}/{env}/{label}`, where the default bindings are
The Config Service serves property sources from `/{name}/{env}/{label}`, where the default bindings in the
client app are
* "name" = `${spring.application.name}`
* "env" = `${spring.profiles.active}` (actually `Environment.getActiveProfiles()`)
@@ -349,18 +350,24 @@ 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,
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. Every context in
the hierarchy can also (in principle) have a different
`spring.application.name` and hence a different remote property source
if there is a Config Server. Remember that properties from a child
context override those in the parent.
(`parent()`, `child()` and `sibling()`). The bootstrap context will be
the parent of the most senior ancestor that you create yourself.
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. Every context in the hierarchy can
also (in principle) have a different `spring.application.name` and
hence a different remote property source if there is a Config
Server. Normal Spring application context behaviour rules apply to
property resolution: properties from a child context override those in
the parent, by name and also by property source name (if the child has
a property source with the same name as the parent, the one from the
parent is not included in the child).
Note that the `SpringApplicationBuilder` allows you to share an
`Environment` amongst the whole hierarchy, but that is not the
default. Thus, 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.
[[customizing-bootstrap-properties]]
=== Changing the Location of Bootstrap Properties