E.g. spring.cloud.config.server.overrides.foo=$\{bar} will evaluate
to foo=${bar} in the client's Environment (allowing local replacement
of the placeholder instead of on the configserver).
This commit adds a getDefaultLabel() method to the EnvironmentRepository
interface. SvnKitEnvironmentRepository returns 'trunk', while all other
implementations return 'master'. ConfigServerMvcConfiguration and
ConfigServerBootstrapConfiguration will utilize labels configured on
the client and server before falling back to the repository's default
label.
Resolves#107
The SCM repositories have a "clean()" method to strip out the server's
own configuration files from the property sources shipped to remote
clients. The "native" one didn't have that method so this change adds
it with a similar implementation to the SCM case, except slightly
more complicated because of the extra search locations added by the
"label" parameter.
Also changes the name SpringApplicationEnvironmentRepository to
NativeEnvironmentRepository to match the profile and the config properties.
Fixes gh-109
This change adds a listener that inserts a PropertySource really early
so that spring.cloud.config.enabled=false is the default in a config
server. It can be overridden if the user primes the Environment with
spring.cloud.config.enabled=true.
See gh-104
Spring MVC lops off the "extension" from request paths by default
(causing no end of other problems), but in this case making it
impossible, or unintuitive at best, to use version-like labels
in git repositories (e.g. 1.0.0). This change makes the mapping
a regex match which includes the whole path, not just the stem.
Fixes gh-94
The connectors project doesn't use any of the subpackages we do
here so if we movethe Environment and PropertySource into a sub-
package it should be safe.
See gh-91
This implementation adds multiple git repositories support to Spring Cloud Config Server.
By giving the following properties file:
info:
component: Config Server
spring:
application:
name: configserver
jmx:
default_domain: cloud.config.server
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
repos:
- patterns: iceycake-*
uri: https://github.com/iceycake/config-repo
- patterns: project1-*,*-project1
uri: https://github.com/spring-cloud-samples/config-repo-1
with uri:
/{application}/{profile}/{label}
where
spring.cloud.config.server.git.uri is the default git repository
spring.cloud.config.server.repos is a mapping between a git repository and
a string pattern that matches the {application} string in the endpoint.
Fixes gh-82, fixes gh-58
Setting this flag to "true" makes the config server load its own
configuration from the git repository (hence both have to be
confifgured in bootstrap.yml)
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
... 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
ConfigServerProperties is now used to store global properties
for the config server (like the path prefix and bootstrap flag)
under spring.cloud.config.server.* so git specific ones have
been pushed down to spring.cloud.config.server.git.* (similarly
for git->native).
At the same time introduce spring.cloud.config.server.defaultLabel
for the deafult git label (defaults to "master").
Fixes gh-28
I think it's a good idea to provide an executable jar (good
getting started experience), but it wasn't working very well.
The biggest problem was the missing main() method, but that
was easy to fix. More interestingly I have changed the default
config name to "configserver" so "configserver.yml" is loaded
to set the default config for the standalone jar, and this file
can easily be ignored in a customized server.
Fixes gh-17
If user provides encrypt.key or encrypt.keyStore.* in bootstrap.yml
the ApplicationContext will now contain a TextEncryptor. This will
also be automatically applied to Environment values that start with
'{cipher}'.
