Since the bootstrap customizations are applied in ApplicationContextInitializers
they come too late to affect the logging levels. But the LoggingRebinder listener
isn't installed yet, and the context is not ready for events to be published. So
to get the logging changes in as early as possible we actually need to explicitly
apply them in the property source initializer as soon as the remote properties are
available.
Fixes gh-74, fixes gh-75
Also affects properties endpoints. The order of property sources
should be reversed when creating the properties to mimic accurately
the behaviuour of Spring's Environment.
Fixes gh-71
In the server we use a SpringApplicationEnvironmentRepository to load
the YAML and properties files from git (or locally). It creates a mini
SpringApplication so as to faithfully replicate the way the Environment
is created. Unfortunately that can have side effects on the server
application itself (e.g. setting log levels). In particular if the
mini SpringApplication fails to start then the log levels could be
left in a "preInitialized" state with all log levels OFF by default.
This change ensures that the server logs all errors when loading YAML
and properties files, and also that the client logs the error response
if it is JSON (as it should be).
Fixes gh-66, fixes gh-67
Since JGit cannot use the "local" protocol (only git, ssh and https) we can't
use file:/... repositories in the same way as the other protocols. Formerly
we would copy the whole directory and use the copy as a local cache. But then
users are confused when they commit changes to the "remote" and they don't
show up in the server. It seems less confusing to simply use the local
repository as the basedir (although it does mean that ssh: should be used
if you are scaling up the config server).
Fixes gh-63
The default behaviour is the same as before, so a config client
adds the remote property sources "first" (i.e. ahead of system
properties). If the user sets up a remote config repo with
spring.cloud.config.overrideSystemProperties=false they can
change this behaviour and insert the new property source after
systemEnvironment (i.e. before local config files but after the
other local sources). Of course using an `application.yml` on
the server you can change the default for all applications.
There is also a new feature in the config server where the operator
can add a map of override properties in
spring.cloud.config.server.overrides.* and have them added with
highest priority in the Environment returned from the server.
Using that the operator can prevent config repositories from
changing the override behaviour by setting
spring.cloud.config.allowOverride=false.
Fixes gh-57
There are still some problematic areas (see SPR-12486) where users
might be surprised, but at least there now is an error message for the
specific case of @RefreshScope on @Configuration.
Fixes gh-43
Fixes gh-44 because it allows an extra layer to insert
an @AutoConfigureAfter.
Also adds some more integration tests for refresh scope
Per gh-43, note that @Configuration does not play well
with @RefreshScope (see @Ignored test case).
... in addition to top level. That way users can
organize their config files, e.g. by subsystem.
Subdirectories have *higher* precedence than the
top level. Users configure which subdirectories to
search through spring.cloud.config.server.git.searchPaths
(array or String, so csv in config file, default empty).
Fixes gh-36
