There could be consequences for apps that have more complex context
hierarchies, but RestartEndpoint doesn't work well at all for those
apps anyway, so we are probably safe to just make changes in the
endpoint itself.
Fixes gh-333
It's not super expensive, but it all adds up, and rebinding beans
that don't need to be rebound is wasteful. This change should improve
things in three places:
The ConfigurationPropertiesRebinder
has always done a pre-emptive re-bind on startup, which was a bit
of a blunt instrument, since all we really wanted as to rebind the
beans in the parent context (to the current context's Environment).
The rebinding always happened twice for every bean because we
explicitly called into the ConfigurationPropertiesPostProcessor
directly as well as indirectly through the initialization callbacks.
Rebinding in response to an EnvironmentChangeEvent was not able to
distinguish between events published locally and by child contexts.
The child context always binds the parent's beans anyway, so you
don't need to do it twice.
A context refresh is actually only trying to recalculate environment
properties. Spring Boot doesn't provide an explicit API for that so
we create a "mini application" to mimic the startup. There is no
need for the logging system to be touched at all, so we can try
and filter out the listeners we know might do that.
Fixes gh-260
We need to tread a very fine line. Ideally the process of refreshing
the Environment builds it back exactly as happened on startup.
In particular we probably don't want to have things like
application.properties already there when we start the process.
This change replaces the more liberal copy of all property sources
only a select few (actually only one), paremeterized as a constant.
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
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.
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
Given the following in one property source
```
mine[0].someValue=Foo
mine[0].someKey={cipher}XXXX
mine[1].someValue=Bar
mine[1].someKey={cipher}XXXX
yours[0].anotherKey=Baz
```
only `mine[*].someKey` were added to "decrypted" property source. Due to house spring boot manages indexed properties, they can not be merged across property source. This change includes all indexed properties in the "decrypted" property source if any one of them is encrypted.
In the above example, `yours[*].*` is included even though unrelated.
fixes gh-466
A couple of tests here make assumptions about the property source
names added using @IntegrationTest. If we are a bit more defensive
and search for a source with a matching name instead of grabbing
one by the precise name, we can have tests that pass in Boot 1.3
and 1.4.
When the bootstrap properties are added back into the main Environment
we have to be careful that any source that is already there (such as
one that was added in a Spring Boot EnvironmentPostProcessor) is not
replaced in the wrong order.
Fixes gh-90
