diff --git a/multi/multi__spring_cloud_commons_common_abstractions.html b/multi/multi__spring_cloud_commons_common_abstractions.html index ff0feab1..079bfb94 100644 --- a/multi/multi__spring_cloud_commons_common_abstractions.html +++ b/multi/multi__spring_cloud_commons_common_abstractions.html @@ -10,7 +10,15 @@ 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.

2.2 ServiceRegistry

Commons now provides a ServiceRegistry interface that provides methods such as register(Registration) and deregister(Registration), which let you provide custom registered services. +Otherwise, it can bubble up as the description of the rolled up HealthIndicator.

2.1.2 Ordering DiscoveryClient instances

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 +the getOrder() method so that it returns the value that is suitable for your setup. Apart from this, you can use +properties to set the order of the DiscoveryClient +implementations provided by Spring Cloud, among others ConsulDiscoveryClient, EurekaDiscoveryClient and +ZookeeperDiscoveryClient. In order to do it, you just need to set the +spring.cloud.{clientIdentifier}.discovery.order (or eureka.client.order for Eureka) property to the desired value.

2.2 ServiceRegistry

Commons now provides a ServiceRegistry interface that provides methods such as register(Registration) and deregister(Registration), which let you provide custom registered services. Registration is a marker interface.

The following example shows the ServiceRegistry in use:

@Configuration
 @EnableDiscoveryClient(autoRegister=false)
 public class MyConfiguration {
diff --git a/multi/multi_spring-cloud-commons.html b/multi/multi_spring-cloud-commons.html
index 7fead57c..e4e392df 100644
--- a/multi/multi_spring-cloud-commons.html
+++ b/multi/multi_spring-cloud-commons.html
@@ -1,3 +1,3 @@
 
       
-   Cloud Native Applications
Cloud Native Applications
   Next
Cloud Native Applications
Table of Contents
1. Spring Cloud Context: Application Context Services
1.1. The Bootstrap Application Context
1.2. Application Context Hierarchies
1.3. Changing the Location of Bootstrap Properties
1.4. Overriding the Values of Remote Properties
1.5. Customizing the Bootstrap Configuration
1.6. Customizing the Bootstrap Property Sources
1.7. Logging Configuration
1.8. Environment Changes
1.9. Refresh Scope
1.10. Encryption and Decryption
1.11. Endpoints
2. Spring Cloud Commons: Common Abstractions
2.1. @EnableDiscoveryClient
2.1.1. Health Indicator
2.2. ServiceRegistry
2.2.1. ServiceRegistry Auto-Registration
2.2.2. Service Registry Actuator Endpoint
2.3. Spring RestTemplate as a Load Balancer Client
2.4. Spring WebClient as a Load Balancer Client
2.4.1. Retrying Failed Requests
2.5. Multiple RestTemplate objects
2.6. Spring WebFlux WebClient as a Load Balancer Client
2.7. Ignore Network Interfaces
2.8. HTTP Client Factories
2.9. Enabled Features
2.9.1. Feature types
2.9.2. Declaring features
   Next
   

\ No newline at end of file
+   Cloud Native Applications
Cloud Native Applications
   Next
Cloud Native Applications
Table of Contents
1. Spring Cloud Context: Application Context Services
1.1. The Bootstrap Application Context
1.2. Application Context Hierarchies
1.3. Changing the Location of Bootstrap Properties
1.4. Overriding the Values of Remote Properties
1.5. Customizing the Bootstrap Configuration
1.6. Customizing the Bootstrap Property Sources
1.7. Logging Configuration
1.8. Environment Changes
1.9. Refresh Scope
1.10. Encryption and Decryption
1.11. Endpoints
2. Spring Cloud Commons: Common Abstractions
2.1. @EnableDiscoveryClient
2.1.1. Health Indicator
2.1.2. Ordering DiscoveryClient instances
2.2. ServiceRegistry
2.2.1. ServiceRegistry Auto-Registration
2.2.2. Service Registry Actuator Endpoint
2.3. Spring RestTemplate as a Load Balancer Client
2.4. Spring WebClient as a Load Balancer Client
2.4.1. Retrying Failed Requests
2.5. Multiple RestTemplate objects
2.6. Spring WebFlux WebClient as a Load Balancer Client
2.7. Ignore Network Interfaces
2.8. HTTP Client Factories
2.9. Enabled Features
2.9.1. Feature types
2.9.2. Declaring features
   Next
   

\ No newline at end of file
diff --git a/single/spring-cloud-commons.html b/single/spring-cloud-commons.html
index c0b22044..a025397c 100644
--- a/single/spring-cloud-commons.html
+++ b/single/spring-cloud-commons.html
@@ -1,6 +1,6 @@
 
       
-   Cloud Native Applications
Cloud Native Applications
Table of Contents
1. Spring Cloud Context: Application Context Services
1.1. The Bootstrap Application Context
1.2. Application Context Hierarchies
1.3. Changing the Location of Bootstrap Properties
1.4. Overriding the Values of Remote Properties
1.5. Customizing the Bootstrap Configuration
1.6. Customizing the Bootstrap Property Sources
1.7. Logging Configuration
1.8. Environment Changes
1.9. Refresh Scope
1.10. Encryption and Decryption
1.11. Endpoints
2. Spring Cloud Commons: Common Abstractions
2.1. @EnableDiscoveryClient
2.1.1. Health Indicator
2.2. ServiceRegistry
2.2.1. ServiceRegistry Auto-Registration
2.2.2. Service Registry Actuator Endpoint
2.3. Spring RestTemplate as a Load Balancer Client
2.4. Spring WebClient as a Load Balancer Client
2.4.1. Retrying Failed Requests
2.5. Multiple RestTemplate objects
2.6. Spring WebFlux WebClient as a Load Balancer Client
2.7. Ignore Network Interfaces
2.8. HTTP Client Factories
2.9. Enabled Features
2.9.1. Feature types
2.9.2. Declaring features
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 Applications
Cloud Native Applications
Table of Contents
1. Spring Cloud Context: Application Context Services
1.1. The Bootstrap Application Context
1.2. Application Context Hierarchies
1.3. Changing the Location of Bootstrap Properties
1.4. Overriding the Values of Remote Properties
1.5. Customizing the Bootstrap Configuration
1.6. Customizing the Bootstrap Property Sources
1.7. Logging Configuration
1.8. Environment Changes
1.9. Refresh Scope
1.10. Encryption and Decryption
1.11. Endpoints
2. Spring Cloud Commons: Common Abstractions
2.1. @EnableDiscoveryClient
2.1.1. Health Indicator
2.1.2. Ordering DiscoveryClient instances
2.2. ServiceRegistry
2.2.1. ServiceRegistry Auto-Registration
2.2.2. Service Registry Actuator Endpoint
2.3. Spring RestTemplate as a Load Balancer Client
2.4. Spring WebClient as a Load Balancer Client
2.4.1. Retrying Failed Requests
2.5. Multiple RestTemplate objects
2.6. Spring WebFlux WebClient as a Load Balancer Client
2.7. Ignore Network Interfaces
2.8. HTTP Client Factories
2.9. Enabled Features
2.9.1. Feature types
2.9.2. Declaring features
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.
@@ -105,7 +105,15 @@ 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.
2.2 ServiceRegistry
Commons now provides a ServiceRegistry interface that provides methods such as register(Registration) and deregister(Registration), which let you provide custom registered services.
+Otherwise, it can bubble up as the description of the rolled up HealthIndicator.
2.1.2 Ordering DiscoveryClient instances
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
+the getOrder() method so that it returns the value that is suitable for your setup. Apart from this, you can use
+properties to set the order of the DiscoveryClient
+implementations provided by Spring Cloud, among others  ConsulDiscoveryClient, EurekaDiscoveryClient and
+ZookeeperDiscoveryClient. In order to do it, you just need to set the
+spring.cloud.{clientIdentifier}.discovery.order (or eureka.client.order for Eureka) property to the desired value.
2.2 ServiceRegistry
Commons now provides a ServiceRegistry interface that provides methods such as register(Registration) and deregister(Registration), which let you provide custom registered services.
 Registration is a marker interface.
The following example shows the ServiceRegistry in use:
@Configuration
 @EnableDiscoveryClient(autoRegister=false)
 public class MyConfiguration {
diff --git a/spring-cloud-commons.xml b/spring-cloud-commons.xml
index 8f4c4292..c3f35cea 100644
--- a/spring-cloud-commons.xml
+++ b/spring-cloud-commons.xml
@@ -280,6 +280,18 @@ To disable it, set spring.cloud.discovery.client.health-indicator.enabl
 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.
 
+

+Ordering <literal>DiscoveryClient</literal> instances
+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
+the getOrder() method so that it returns the value that is suitable for your setup. Apart from this, you can use
+properties to set the order of the DiscoveryClient
+implementations provided by Spring Cloud, among others  ConsulDiscoveryClient, EurekaDiscoveryClient and
+ZookeeperDiscoveryClient. In order to do it, you just need to set the
+spring.cloud.{clientIdentifier}.discovery.order (or eureka.client.order for Eureka) property to the desired value.
+

 
 

 ServiceRegistry