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
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
Use SystemEnvironmentPropertySource so that env vars can be
encrypted as well as property values (i.e. FOO_BAR will bind to
@Value("foo.bar")).
Fixes gh-89, fixes gh-87
When the RefreshEndpoint makes a new Environment it creates a new
ApplicationContext with (hopefully) empty sources. If the user has
set spring.main.sources it won't be empty, so we should take care
to mask it off in the process.
Fixes gh-79
Repots DOWN if there are errors in RefreshScope or
ConfigurationProperties rebinding, N.B. RefreshScope instantiates
its beans lazily after a refresh by default, so you won't see an
error until the bean is used.
Fixes gh-85
The fact that PropertySourceBootstrapConfiguration was re-using the
"bootstrap" property source name from the listener was a problem. The
listener has to be able to manage its own temporary property source name.
Fixes gh-83
The bootstrap.properties need to stick with the default properties
during the process of initializing the application.properties
otherwise the ordering ends up wrong because of the addLast()
semantics in an Environment merge. To do this is a bit ugly with
the additional constraint that the default properties has to
remain a MapPropertySource (so that other processors can append
to it if needed). So we created a custom extension of
MapPropertySource that also carries all the bootstrap properties
during the phase where the application.properties are being
processed, but unpacks them as soon as possible afterwards
in an ApplicationContextInitializer, preserving the order, but
making the bootstrap.properties available effectively for the
whole of the startup and initializaion phase of the main context.
The biggest problem addressed here is one where an
EnvironmentPostProcessor (reasonably) adds entries to the
defaultProperties in the bootstrap context, but then that
property source is not merged with the parent, or is merged
too late (because it only happens when the application context
parent is set). The result would be that things that were activated
during bootstrap would be not be activated in the main context, or
would be activated too late (early enough for beans to bind to but
not for other listeners and post processors to get access to the
additional properties).
See https://github.com/spring-cloud/spring-cloud-sleuth/issues/126
We only need one special name for a property source. In the end it
gets used twice, but this simplifies the logic a bit and ensures that
there is never a PropertySource with that name and things like
spring.application.name=bootstrap in it.
This ensures that any fetaures that require a bean to be instantiated
(for instance @Scheduled) behave the same for @RefreshScope and normal
singletons.
Fixes gh-74
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
