Otherwise multiple instances of a scoped target can be created
if several threads need one at the same time. This isn't always
going to be a problem, but it breaks the singleton semantics, and
might lead to surprising results and/or performance issues if bean
creation is expensive.
It's kind of a corner case, but not a very small corner: if a /refresh
leads to a change in a key that was overridden from its default value (e.g.
n a profile-specific config file) then the key is not identified as changed.
The change is still applied.
This commit fixes the key computation and adds a couple of tests.
Fixes gh-73
The problem is that we do want bootstrap properties to override
default properties in most cases, but if they are decrypted those
values have to be added with the highest possible precedence.
Fixes gh-54
Also adds a propertySource with those values:
"springCloudClientHostInfo": {
"spring.cloud.client.hostname": "myhostname",
"spring.cloud.client.ipAddress": "192.168.2.112"
},
fixes gh-47
EnvironmentChangeEvent should come before the RefreshScopeRefreshedEvent
so that all the @ConfigurationProperties are fully bound when the refresh
happens.
The main driver for this was a config server use case, where the server
wants to configure its own properties in the remote repo. It was working
up to a point, but the beans in bootstrap context were not refreshed
after the Environment was built so you had to manually refresh them to
get them to point to (e.g.) config repos configured remotely.
Fixes https://github.com/spring-cloud/spring-cloud-config/issues/139
Dave Syer
Spencer Gibb
Stephane Nicoll
Glenn Renfro