Patterns such as service discovery, load balancing, and circuit breakers lend themselves to a common abstraction layer that can be consumed by all Spring Cloud clients, independent of the implementation (for example, discovery with Eureka or Consul).
Spring Cloud Commons provides the @EnableDiscoveryClient annotation.
+
Patterns such as service discovery, load balancing, and circuit breakers lend themselves to a common abstraction layer that can be consumed by all Spring Cloud clients, independent of the implementation (for example, discovery with Eureka or Consul).
Spring Cloud Commons provides the @EnableDiscoveryClient annotation.
This looks for implementations of the DiscoveryClient interface with META-INF/spring.factories.
Implementations of the Discovery Client add a configuration class to spring.factories under the org.springframework.cloud.client.discovery.EnableDiscoveryClient key.
Examples of DiscoveryClient implementations include Spring Cloud Netflix Eureka, Spring Cloud Consul Discovery, and Spring Cloud Zookeeper Discovery.
By default, implementations of DiscoveryClient auto-register the local Spring Boot server with the remote discovery server.
@@ -10,7 +10,7 @@ To disable the composite HealthIndicator, set HealthIndicator based on DiscoveryClient is auto-configured (DiscoveryClientHealthIndicator).
To disable it, set spring.cloud.discovery.client.health-indicator.enabled=false.
To disable the description field of the DiscoveryClientHealthIndicator, set spring.cloud.discovery.client.health-indicator.include-description=false.
-Otherwise, it can bubble up as the description of the rolled up HealthIndicator.
DiscoveryClient interface extends Ordered. This is useful when using multiple discovery
+Otherwise, it can bubble up as the description of the rolled up HealthIndicator.
DiscoveryClient interface extends Ordered. This is useful when using multiple discovery
clients, as it allows you to define the order of the returned discovery clients, similar to
how you can order the beans loaded by a Spring application. By default, the order of any DiscoveryClient is set to
0. If you want to set a different order for your custom DiscoveryClient implementations, you just need to override
diff --git a/multi/multi__spring_cloud_context_application_context_services.html b/multi/multi__spring_cloud_context_application_context_services.html
index 99db794c..e28106df 100644
--- a/multi/multi__spring_cloud_context_application_context_services.html
+++ b/multi/multi__spring_cloud_context_application_context_services.html
@@ -1,8 +1,8 @@
Spring Boot has an opinionated view of how to build an application with Spring. +
Spring Boot has an opinionated view of how to build an application with Spring. For instance, it has conventional locations for common configuration files and has endpoints for common management and monitoring tasks. -Spring Cloud builds on top of that and adds a few features that probably all components in a system would use or occasionally need.
A Spring Cloud application operates by creating a “bootstrap” context, which is a parent context for the main application. +Spring Cloud builds on top of that and adds a few features that probably all components in a system would use or occasionally need.
A Spring Cloud application operates by creating a “bootstrap” context, which is a parent context for the main application.
It is responsible for loading configuration properties from the external sources and for decrypting properties in the local external configuration files.
The two contexts share an Environment, which is the source of external properties for any Spring application.
By default, bootstrap properties (not bootstrap.properties but properties that are loaded during the bootstrap phase) are added with high precedence, so they cannot be overridden by local configuration.
The bootstrap context uses a different convention for locating external configuration than the main application context. @@ -16,16 +16,16 @@ The following listing shows an example:
bootstrap.yml. config: uri: ${SPRING_CONFIG_URI:http://localhost:8888}
If your application needs any application-specific configuration from the server, it is a good idea to set the spring.application.name (in bootstrap.yml or application.yml).
You can disable the bootstrap process completely by setting spring.cloud.bootstrap.enabled=false (for example, in system properties).
If you build an application context from SpringApplication or SpringApplicationBuilder, then the Bootstrap context is added as a parent to that context.
-It is a feature of Spring that child contexts inherit property sources and profiles from their parent, so the “main” application context contains additional property sources, compared to building the same context without Spring Cloud Config.
-The additional property sources are:
- “bootstrap”: If any
PropertySourceLocatorsare found in the Bootstrap context and if they have non-empty properties, an optionalCompositePropertySourceappears with high priority. +It is a feature of Spring that child contexts inherit property sources and profiles from their parent, so the “main” application context contains additional property sources, compared to building the same context without Spring Cloud Config. +The additional property sources are:- “bootstrap”: If any
PropertySourceLocatorsare found in the Bootstrap context and if they have non-empty properties, an optionalCompositePropertySourceappears with high priority. An example would be properties from the Spring Cloud Config Server. -See “Section 1.6, “Customizing the Bootstrap Property Sources”” for instructions on how to customize the contents of this property source. - “applicationConfig: [classpath:bootstrap.yml]” (and related files if Spring profiles are active): If you have a
bootstrap.yml(or.properties), those properties are used to configure the Bootstrap context. +See “Section 1.6, “Customizing the Bootstrap Property Sources”” for instructions on how to customize the contents of this property source. - “applicationConfig: [classpath:bootstrap.yml]” (and related files if Spring profiles are active): If you have a
bootstrap.yml(or.properties), those properties are used to configure the Bootstrap context. Then they get added to the child context when its parent is set. They have lower precedence than theapplication.yml(or.properties) and any other property sources that are added to the child as a normal part of the process of creating a Spring Boot application. -See “Section 1.3, “Changing the Location of Bootstrap Properties”” for instructions on how to customize the contents of these property sources.
Because of the ordering rules of property sources, the “bootstrap” entries take precedence. +See “Section 1.3, “Changing the Location of Bootstrap Properties”” for instructions on how to customize the contents of these property sources.
- “bootstrap”: If any
Because of the ordering rules of property sources, the “bootstrap” entries take precedence.
However, note that these do not contain any data from bootstrap.yml, which has very low precedence but can be used to set defaults.
You can extend the context hierarchy by setting the parent context of any ApplicationContext you create — for example, by using its own interface or with the SpringApplicationBuilder convenience methods (parent(), child() and sibling()).
The bootstrap context is the parent of the most senior ancestor that you create yourself.
-Every context in the hierarchy has its own “bootstrap” (possibly empty) property source to avoid promoting values inadvertently from parents down to their descendants.
+Every context in the hierarchy has its own “bootstrap” (possibly empty) property source to avoid promoting values inadvertently from parents down to their descendants.
If there is a Config Server, every context in the hierarchy can also (in principle) have a different spring.application.name and, hence, a different remote property source.
Normal Spring application context behavior rules apply to property resolution: properties from a child context override those in
the parent, by name and also by property source name.
@@ -34,14 +34,14 @@ Thus, sibling contexts, in particular, do not need to have the same profiles or
Those properties behave like the spring.config.* variants with the same name.
In fact, they are used to set up the bootstrap ApplicationContext by setting those properties in its Environment.
If there is an active profile (from spring.profiles.active or through the Environment API in the
-context you are building), properties in that profile get loaded as well, the same as in a regular Spring Boot app — for example, from bootstrap-development.properties for a development profile.
The property sources that are added to your application by the bootstrap context are often “remote” (from example, from Spring Cloud Config Server).
+context you are building), properties in that profile get loaded as well, the same as in a regular Spring Boot app — for example, from bootstrap-development.properties for a development profile.
The property sources that are added to your application by the bootstrap context are often “remote” (from example, from Spring Cloud Config Server).
By default, they cannot be overridden locally.
If you want to let your applications override the remote properties with their own System properties or config files, the remote property source has to grant it permission by setting spring.cloud.config.allowOverride=true (it does not work to set this locally).
Once that flag is set, two finer-grained settings control the location of the remote properties in relation to system properties and the application’s local configuration:
spring.cloud.config.overrideNone=true: Override from any local property source.spring.cloud.config.overrideSystemProperties=false: Only system properties, command line arguments, and environment variables (but not the local config files) should override the remote settings.
The bootstrap context can be set to do anything you like by adding entries to /META-INF/spring.factories under a key named org.springframework.cloud.bootstrap.BootstrapConfiguration.
This holds a comma-separated list of Spring @Configuration classes that are used to create the context.
Any beans that you want to be available to the main application context for autowiring can be created here.
There is a special contract for @Beans of type ApplicationContextInitializer.
-If you want to control the startup sequence, classes can be marked with an @Order annotation (the default order is last).
![[Warning]](images/warning.png) | Warning | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
When adding custom
The bootstrap process ends by injecting initializers into the main The default property source for external configuration added by the bootstrap process is the Spring Cloud Config Server, but you can add additional sources by adding beans of type Cloud Native is a style of application development that encourages easy adoption of best practices in the areas of continuous delivery and value-driven development. + Cloud Native is a style of application development that encourages easy adoption of best practices in the areas of continuous delivery and value-driven development. A related discipline is that of building 12-factor Applications, in which development practices are aligned with delivery and operations goals — for instance, by using declarative programming and management and monitoring. Spring Cloud facilitates these styles of development in a number of specific ways. The starting point is a set of features to which all components in a distributed system need easy access. Many of those features are covered by Spring Boot, on which Spring Cloud builds. Some more features are delivered by Spring Cloud as two libraries: Spring Cloud Context and Spring Cloud Commons. diff --git a/multi/multi_spring-cloud-commons.html b/multi/multi_spring-cloud-commons.html index e4e392df..9f5cb8ae 100644 --- a/multi/multi_spring-cloud-commons.html +++ b/multi/multi_spring-cloud-commons.html @@ -1,3 +1,3 @@ -Table of Contents
Table of Contents
Table of Contents
Cloud Native is a style of application development that encourages easy adoption of best practices in the areas of continuous delivery and value-driven development. + Table of Contents
Cloud Native is a style of application development that encourages easy adoption of best practices in the areas of continuous delivery and value-driven development. A related discipline is that of building 12-factor Applications, in which development practices are aligned with delivery and operations goals — for instance, by using declarative programming and management and monitoring. Spring Cloud facilitates these styles of development in a number of specific ways. The starting point is a set of features to which all components in a distributed system need easy access. Many of those features are covered by Spring Boot, on which Spring Cloud builds. Some more features are delivered by Spring Cloud as two libraries: Spring Cloud Context and Spring Cloud Commons.
@@ -8,7 +8,7 @@ Spring Cloud Context provides utilities and special services for the Extract the files into the JDK/jre/lib/security folder for whichever version of JRE/JDK x64/x86 you use. Spring Cloud is released under the non-restrictive Apache 2.0 license.
If you would like to contribute to this section of the documentation or if you find an error, you can find the source code and issue trackers for the project at github. Spring Boot has an opinionated view of how to build an application with Spring. For instance, it has conventional locations for common configuration files and has endpoints for common management and monitoring tasks. -Spring Cloud builds on top of that and adds a few features that probably all components in a system would use or occasionally need. A Spring Cloud application operates by creating a “bootstrap” context, which is a parent context for the main application. +Spring Cloud builds on top of that and adds a few features that probably all components in a system would use or occasionally need. A Spring Cloud application operates by creating a “bootstrap” context, which is a parent context for the main application.
It is responsible for loading configuration properties from the external sources and for decrypting properties in the local external configuration files.
The two contexts share an The bootstrap context uses a different convention for locating external configuration than the main application context. @@ -22,16 +22,16 @@ The following listing shows an example: bootstrap.yml. config: uri: ${SPRING_CONFIG_URI:http://localhost:8888}
If your application needs any application-specific configuration from the server, it is a good idea to set the You can disable the bootstrap process completely by setting If you build an application context from
Because of the ordering rules of property sources, the “bootstrap” entries take precedence.
However, note that these do not contain any data from You can extend the context hierarchy by setting the parent context of any The property sources that are added to your application by the bootstrap context are often “remote” (from example, from Spring Cloud Config Server).
+context you are building), properties in that profile get loaded as well, the same as in a regular Spring Boot app — for example, from The property sources that are added to your application by the bootstrap context are often “remote” (from example, from Spring Cloud Config Server).
By default, they cannot be overridden locally.
If you want to let your applications override the remote properties with their own System properties or config files, the remote property source has to grant it permission by setting
The bootstrap context can be set to do anything you like by adding entries to
Patterns such as service discovery, load balancing, and circuit breakers lend themselves to a common abstraction layer that can be consumed by all Spring Cloud clients, independent of the implementation (for example, discovery with Eureka or Consul). Spring Cloud Commons provides the By default, implementations of
|
![[Note]](images/note.png)