If there were *no* bootstrapProperties (i.e. properties added by
PropertySourceLocators) on startup, and then in a refresh event
some new sources were picked up, they would have been added to the
end, instead of the beginning of the list.
Fixes https://github.com/spring-cloud/spring-cloud-config/issues/815
The old hack in RefreshScope has been replaced with a new hack.
It has to "reset" the ConfigurationProperties bean post processor
and the new rebinder API has changed the internals of that, so
we needed to adjust.
When the Environment is resetted the EnvironmentChangedEvent always
contains an empty keySet, since the live view of the cleared map was
used. This commit fixes this.
Also adjusts bootstrap listener to be smarter about default
properties:
It's better not to use the default properties at all because the
user might pass some in and we don't want to overwrite them. Before
Boot 2.0 we got away with it, but since 2.0 we have to be more
cautious.
Instead it depends on ContextRefresher with actually does the work.
This allows applications to use the listener even if they don't depend
on actuator.
fixes gh-171
The fix for gh-153 was sensible, but has now exposed another issue
which is that the bootstrap initializers, whilst they are now only
created once, actually only get applied to the parent context
in a hierarchy.
Most of the time this doesn't matter because the child contexts all
benefit from environment changes and additional beans added
to the parent. If the children are supposed to actually have
different environments, though, there is a problem. So this change
locates the existing bootstrap context and applies it to each
new context created separately.
Unfortunately we have to use reflection to do that for now because
there is no way to discover the parent with a public API before
the context is refreshed.
See gh-190
For RefreshScope this stops Spring from moaning about the @Bean
method with a WARN log (which is benign but hard to get rid of
and confusing for users).
See gh-401
