The Config Server can be embedded in another web application by -setting "spring.cloud.config.server.prefix" (default empty), e.g. to -"/config". If you do that, then you probably want to bootstrap the app -containing the Config Server from the same remote repository from -which all the other remote apps get their configuration properties -(otherwise it is just a normal Spring Boot application since it won’t -have a Config Server to contact when it starts). To do that you just -need to make sure that the (optional) property -"spring.cloud.config.server.bootstrap" is "true".
-You are free to secure your Config Server in any way that makes sense
@@ -869,7 +854,7 @@ your application.yml for the Config Server:
The Config Server runs best as a standalone application, but if you
need to you can embed it in another application. Just use the
@@ -893,7 +878,7 @@ application developer), and it will also pick up some additional
useful features related to Environment change events.
This is the default behaviour for any application which has the Spring
Cloud Config Client on the classpath. When a config client starts up
@@ -909,7 +894,7 @@ with the server address in spring.cloud.config.uri (defaults to
If you are using Spring Cloud Netflix and Eureka Service Discovery, then you can have the Config Server register with Eureka if you want @@ -948,14 +933,28 @@ use those to:
This covers a large class of refresh use cases, and you can verify the
-changes by visiting the /configprops endpoint (normal Spring Boot
-Actuator feature). For instance a DataSource can have its
-maxPoolSize changed at runtime (the default DataSource created by
-Spring Boot is an @ConfigurationProperties bean) and grow capacity
-dynamically. It does not cover another large class of use cases, where
-you need more control over the refresh, and where you need a
-configuration change to be atomic over the whole
+
Note that the Config Client does not by default poll for changes in
+the Environment, and generally we would not recommend that approach
+for detecting changes (although you could set it up with a
+@Scheduled annotation). If you have a scaled-out client application
+then it is better to broadcast the EnvironmentChangedEvent to all
+the instances instead of having them polling for changes (e.g. using
+the Spring Cloud
+Bus).
The EnvironmentChangedEvent covers a large class of refresh use
+cases, as long as you can actually make a change to the Environment
+and publish the event (those APIs are public and part of core
+Spring). You can verify the changes are bound to
+@ConfigurationProperties beans by visiting the /configprops
+endpoint (normal Spring Boot Actuator feature). For instance a
+DataSource can have its maxPoolSize changed at runtime (the
+default DataSource created by Spring Boot is an
+@ConfigurationProperties bean) and grow capacity
+dynamically. Re-binding @ConfigurationProperties does not cover
+another large class of use cases, where you need more control over the
+refresh, and where you need a change to be atomic over the whole
ApplicationContext. To address those concerns we have
@RefreshScope.