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
LoggingSystemShutdownListener runs immediately after
BootstrapApplicationListener and contains the code which used to be
in that to clean up the logging system (and make it go dark). That
is still a little bit of a hack to work around some limitations in
the static logging libraries (via the Spring Boot Logging System
and LoggingApplicationListener).
If the LoggingApplicationListener is then *not* applied in the
ContextRefresher, then we don't need the LoggingSystemShutdownListener
either. In fact we can narrow down the ContextRefresher to be only
interested in the listeners that affect the Environment (of which
we know of only 2). It means that any listeners that are added that
affect the Environment will not be applied, but there are plenty of
more "official" channels for modifying the Environment
(EnvironmentPostProcessor and PropertySourceLocator), so users can
easily migrate to a better implementation.
Completes the work started in 7f687b1, where the call to
LoggingSystem.beforeInitialization() was ommitted which results
in JUL logging never being available in the application.
Partial fix for #131 (but a /refresh is still broken)
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
Anticipating a change in Spring Boot 1.4.1 to support child context
creation without (needless) re-initialization of the logging system,
we need to carefully manage the lifecycle, in particular calling
cleanUp() when we know there are changes in the pipeline.
Fixes gh-125
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.
The new info endpoint doesn't need special treatment to pick up
changes in the Environment, so we can just skip installing the
old bean that manipulates it.
Fixes gh-108
Ryan Baxter
Spencer Gibb
Dave Syer
Matt Benson
Venil Noronha
David Welch