From 3186452eceed71bb5845de07f32ef93994fe6c42 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Wed, 7 Feb 2018 18:29:43 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- ...ing_cloud_commons_common_abstractions.html | 25 ++++++++++-- multi/multi_spring-cloud-commons.html | 2 +- single/spring-cloud-commons.html | 27 +++++++++++-- spring-cloud-commons.xml | 39 ++++++++++++++++++- 4 files changed, 83 insertions(+), 10 deletions(-) diff --git a/multi/multi__spring_cloud_commons_common_abstractions.html b/multi/multi__spring_cloud_commons_common_abstractions.html index 11efe482..6efb18a1 100644 --- a/multi/multi__spring_cloud_commons_common_abstractions.html +++ b/multi/multi__spring_cloud_commons_common_abstractions.html @@ -1,7 +1,7 @@ 2. Spring Cloud Commons: Common Abstractions
2. Spring Cloud Commons: Common Abstractions
Prev   

2. Spring Cloud Commons: Common Abstractions

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 (e.g. discovery via Eureka or Consul).

2.1 @EnableDiscoveryClient

Commons provides the @EnableDiscoveryClient annotation. This looks for implementations of the DiscoveryClient interface via META-INF/spring.factories. Implementations of Discovery Client will add a configuration class to spring.factories under the org.springframework.cloud.client.discovery.EnableDiscoveryClient key. Examples of DiscoveryClient implementations: are Spring Cloud Netflix Eureka, Spring Cloud Consul Discovery and Spring Cloud Zookeeper Discovery.

By default, implementations of DiscoveryClient will auto-register the local Spring Boot server with the remote discovery server. This can be disabled by setting autoRegister=false in @EnableDiscoveryClient.

[Note]Note

The use of @EnableDiscoveryClient is no longer required. It is enough to just have a DiscoveryClient implementation -on the classpath to cause the Spring Boot application to register with the service discovery server.

2.1.1 Health Indicator

Commons creates a Spring Boot HealthIndicator that DiscoveryClient implementations can participate in by implementing DiscoveryHealthIndicator. To disable the composite HealthIndicator set spring.cloud.discovery.client.composite-indicator.enabled=false. A generic 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 which provides methods like register(Registration) and deregister(Registration) which allow you to provide custom registered services. Registration is a marker interface.

@Configuration
+on the classpath to cause the Spring Boot application to register with the service discovery server.

2.1.1 Health Indicator

Commons creates a Spring Boot HealthIndicator that DiscoveryClient implementations can participate in by implementing DiscoveryHealthIndicator. To disable the composite HealthIndicator set spring.cloud.discovery.client.composite-indicator.enabled=false. A generic 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 which provides methods like register(Registration) and deregister(Registration) which allow you to provide custom registered services. Registration is a marker interface.

@Configuration
 @EnableDiscoveryClient(autoRegister=false)
 public class MyConfiguration {
     private ServiceRegistry registry;
@@ -15,7 +15,7 @@ on the classpath to cause the Spring Boot application to register with the servi
         Registration registration = constructRegistration();
         this.registry.register(registration);
     }
-}

Each ServiceRegistry implementation has its own Registry implementation.

2.2.1 ServiceRegistry Auto-Registration

By default, the ServiceRegistry implementation will auto-register the running service. To disable that behavior, there are two methods. You can set @EnableDiscoveryClient(autoRegister=false) to permanently disable auto-registration. You can also set spring.cloud.service-registry.auto-registration.enabled=false to disable the behavior via configuration.

2.2.2 Service Registry Actuator Endpoint

A /service-registry actuator endpoint is provided by Commons. This endpoint relys on a Registration bean in the Spring Application Context. Calling /service-registry/instance-status via a GET will return the status of the Registration. A POST to the same endpoint with a String body will change the status of the current Registration to the new value. Please see the documentation of the ServiceRegistry implementation you are using for the allowed values for updating the status and the values retured for the status.

2.3 Spring RestTemplate as a Load Balancer Client

RestTemplate can be automatically configured to use ribbon. To create a load balanced RestTemplate create a RestTemplate @Bean and use the @LoadBalanced qualifier.

[Warning]Warning

A RestTemplate bean is no longer created via auto configuration. It must be created by individual applications.

@Configuration
+}

Each ServiceRegistry implementation has its own Registry implementation.

2.2.1 ServiceRegistry Auto-Registration

By default, the ServiceRegistry implementation will auto-register the running service. To disable that behavior, there are two methods. You can set @EnableDiscoveryClient(autoRegister=false) to permanently disable auto-registration. You can also set spring.cloud.service-registry.auto-registration.enabled=false to disable the behavior via configuration.

2.2.2 Service Registry Actuator Endpoint

A /service-registry actuator endpoint is provided by Commons. This endpoint relies on a Registration bean in the Spring Application Context. Calling /service-registry via a GET will return the status of the Registration. A POST to the same endpoint with a JSON body will change the status of the current Registration to the new value. The JSON body has to include the status field with the preferred value. Please see the documentation of the ServiceRegistry implementation you are using for the allowed values for updating the status and the values returned for the status. For instance, Eureka’s supported statuses are UP, DOWN, OUT_OF_SERVICE and UNKNOWN.

2.3 Spring RestTemplate as a Load Balancer Client

RestTemplate can be automatically configured to use ribbon. To create a load balanced RestTemplate create a RestTemplate @Bean and use the @LoadBalanced qualifier.

[Warning]Warning

A RestTemplate bean is no longer created via auto configuration. It must be created by individual applications.

@Configuration
 public class MyConfiguration {
 
     @LoadBalanced
@@ -182,4 +182,23 @@ in downstream projects.  In addition, if you provide a bean of type spring.cloud.httpclientfactories.apache.enabled or spring.cloud.httpclientfactories.ok.enabled to
-false.
Prev   
1. Spring Cloud Context: Application Context Services Home 
\ No newline at end of file +false.

2.9 Enabled Features

A /features actuator endpoint is provided by Commons. This endpoint returns features available on the classpath and if they are enabled or not. The information returned includes the feature type, name, version and vendor.

2.9.1 Feature types

There are two types of 'features': abstract and named.

Abstract features are features where an interface or abstract class is defined that an implementation creates, such as DiscoveryClient, LoadBalancerClient or LockService. The abstract class or interface is used to find a bean of that type in the context. The version displayed is bean.getClass().getPackage().getImplementationVersion().

Named features are features that don’t have a particular class they implement, such as "Circuit Breaker", "API Gateway", "Spring Cloud Bus", etc…​ These features require a name and a bean type.

2.9.2 Declaring features

Any module can declare any number of HasFeature beans. Some examples:

@Bean
+public HasFeatures commonsFeatures() {
+  return HasFeatures.abstractFeatures(DiscoveryClient.class, LoadBalancerClient.class);
+}
+
+@Bean
+public HasFeatures consulFeatures() {
+  return HasFeatures.namedFeatures(
+    new NamedFeature("Spring Cloud Bus", ConsulBusAutoConfiguration.class),
+    new NamedFeature("Circuit Breaker", HystrixCommandAspect.class));
+}
+
+@Bean
+HasFeatures localFeatures() {
+  return HasFeatures.builder()
+      .abstractFeature(Foo.class)
+      .namedFeature(new NamedFeature("Bar Feature", Bar.class))
+      .abstractFeature(Baz.class)
+      .build();
+}

Each of these beans should go in an appropriately guarded @Configuration.

Prev   
1. Spring Cloud Context: Application Context Services Home 
\ No newline at end of file diff --git a/multi/multi_spring-cloud-commons.html b/multi/multi_spring-cloud-commons.html index a16ad376..04b3dd77 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. Environment Changes
1.8. Refresh Scope
1.9. Encryption and Decryption
1.10. 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
   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. Environment Changes
1.8. Refresh Scope
1.9. Encryption and Decryption
1.10. 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 diff --git a/single/spring-cloud-commons.html b/single/spring-cloud-commons.html index b3755e56..92725f49 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. Environment Changes
1.8. Refresh Scope
1.9. Encryption and Decryption
1.10. 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

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 Apps 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 and the starting point is a set of features that all components in a distributed system either need or need easy access to when required.

Many of those features are covered by Spring Boot, which we build on in Spring Cloud. Some more are delivered by Spring Cloud as two libraries: Spring Cloud Context and Spring Cloud Commons. Spring Cloud Context provides utilities and special services for the ApplicationContext of a Spring Cloud application (bootstrap context, encryption, refresh scope and environment endpoints). Spring Cloud Commons is a set of abstractions and common classes used in different Spring Cloud implementations (eg. Spring Cloud Netflix vs. Spring Cloud Consul).

If you are getting an exception due to "Illegal key size" and you are using Sun’s JDK, you need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. See the following links for more information:

Extract files into JDK/jre/lib/security folder (whichever version of JRE/JDK x64/x86 you are using).

[Note]Note

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, please find the source code and issue trackers in the project at github.

1. Spring Cloud Context: Application Context Services

Spring Boot has an opinionated view of how to build an application + 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. Environment Changes
1.8. Refresh Scope
1.9. Encryption and Decryption
1.10. 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. A related discipline is that of building 12-factor Apps 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 and the starting point is a set of features that all components in a distributed system either need or need easy access to when required.

Many of those features are covered by Spring Boot, which we build on in Spring Cloud. Some more are delivered by Spring Cloud as two libraries: Spring Cloud Context and Spring Cloud Commons. Spring Cloud Context provides utilities and special services for the ApplicationContext of a Spring Cloud application (bootstrap context, encryption, refresh scope and environment endpoints). Spring Cloud Commons is a set of abstractions and common classes used in different Spring Cloud implementations (eg. Spring Cloud Netflix vs. Spring Cloud Consul).

If you are getting an exception due to "Illegal key size" and you are using Sun’s JDK, you need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. See the following links for more information:

Extract files into JDK/jre/lib/security folder (whichever version of JRE/JDK x64/x86 you are using).

[Note]Note

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, please find the source code and issue trackers in the project at github.

1. Spring Cloud Context: Application Context Services

Spring Boot has an opinionated view of how to build an application with Spring: for instance it has conventional locations for common configuration file, and endpoints for common management and monitoring tasks. Spring Cloud builds on top of that and adds a few features that @@ -188,7 +188,7 @@ features in an application you need to include Spring Security RSA in your classpath (Maven co-ordinates "org.springframework.security:spring-security-rsa") and you also need the full strength JCE extensions in your JVM.

If you are getting an exception due to "Illegal key size" and you are using Sun’s JDK, you need to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. See the following links for more information:

Extract files into JDK/jre/lib/security folder (whichever version of JRE/JDK x64/x86 you are using).

1.10 Endpoints

For a Spring Boot Actuator application there are some additional management endpoints:

  • POST to /env to update the Environment and rebind @ConfigurationProperties and log levels
  • /refresh for re-loading the boot strap context and refreshing the @RefreshScope beans
  • /restart for closing the ApplicationContext and restarting it (disabled by default)
  • /pause and /resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext)

2. Spring Cloud Commons: Common Abstractions

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 (e.g. discovery via Eureka or Consul).

2.1 @EnableDiscoveryClient

Commons provides the @EnableDiscoveryClient annotation. This looks for implementations of the DiscoveryClient interface via META-INF/spring.factories. Implementations of Discovery Client will add a configuration class to spring.factories under the org.springframework.cloud.client.discovery.EnableDiscoveryClient key. Examples of DiscoveryClient implementations: are Spring Cloud Netflix Eureka, Spring Cloud Consul Discovery and Spring Cloud Zookeeper Discovery.

By default, implementations of DiscoveryClient will auto-register the local Spring Boot server with the remote discovery server. This can be disabled by setting autoRegister=false in @EnableDiscoveryClient.

[Note]Note

The use of @EnableDiscoveryClient is no longer required. It is enough to just have a DiscoveryClient implementation -on the classpath to cause the Spring Boot application to register with the service discovery server.

2.1.1 Health Indicator

Commons creates a Spring Boot HealthIndicator that DiscoveryClient implementations can participate in by implementing DiscoveryHealthIndicator. To disable the composite HealthIndicator set spring.cloud.discovery.client.composite-indicator.enabled=false. A generic 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 which provides methods like register(Registration) and deregister(Registration) which allow you to provide custom registered services. Registration is a marker interface.

@Configuration
+on the classpath to cause the Spring Boot application to register with the service discovery server.

2.1.1 Health Indicator

Commons creates a Spring Boot HealthIndicator that DiscoveryClient implementations can participate in by implementing DiscoveryHealthIndicator. To disable the composite HealthIndicator set spring.cloud.discovery.client.composite-indicator.enabled=false. A generic 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 which provides methods like register(Registration) and deregister(Registration) which allow you to provide custom registered services. Registration is a marker interface.

@Configuration
 @EnableDiscoveryClient(autoRegister=false)
 public class MyConfiguration {
     private ServiceRegistry registry;
@@ -202,7 +202,7 @@ on the classpath to cause the Spring Boot application to register with the servi
         Registration registration = constructRegistration();
         this.registry.register(registration);
     }
-}

Each ServiceRegistry implementation has its own Registry implementation.

2.2.1 ServiceRegistry Auto-Registration

By default, the ServiceRegistry implementation will auto-register the running service. To disable that behavior, there are two methods. You can set @EnableDiscoveryClient(autoRegister=false) to permanently disable auto-registration. You can also set spring.cloud.service-registry.auto-registration.enabled=false to disable the behavior via configuration.

2.2.2 Service Registry Actuator Endpoint

A /service-registry actuator endpoint is provided by Commons. This endpoint relys on a Registration bean in the Spring Application Context. Calling /service-registry/instance-status via a GET will return the status of the Registration. A POST to the same endpoint with a String body will change the status of the current Registration to the new value. Please see the documentation of the ServiceRegistry implementation you are using for the allowed values for updating the status and the values retured for the status.

2.3 Spring RestTemplate as a Load Balancer Client

RestTemplate can be automatically configured to use ribbon. To create a load balanced RestTemplate create a RestTemplate @Bean and use the @LoadBalanced qualifier.

[Warning]Warning

A RestTemplate bean is no longer created via auto configuration. It must be created by individual applications.

@Configuration
+}

Each ServiceRegistry implementation has its own Registry implementation.

2.2.1 ServiceRegistry Auto-Registration

By default, the ServiceRegistry implementation will auto-register the running service. To disable that behavior, there are two methods. You can set @EnableDiscoveryClient(autoRegister=false) to permanently disable auto-registration. You can also set spring.cloud.service-registry.auto-registration.enabled=false to disable the behavior via configuration.

2.2.2 Service Registry Actuator Endpoint

A /service-registry actuator endpoint is provided by Commons. This endpoint relies on a Registration bean in the Spring Application Context. Calling /service-registry via a GET will return the status of the Registration. A POST to the same endpoint with a JSON body will change the status of the current Registration to the new value. The JSON body has to include the status field with the preferred value. Please see the documentation of the ServiceRegistry implementation you are using for the allowed values for updating the status and the values returned for the status. For instance, Eureka’s supported statuses are UP, DOWN, OUT_OF_SERVICE and UNKNOWN.

2.3 Spring RestTemplate as a Load Balancer Client

RestTemplate can be automatically configured to use ribbon. To create a load balanced RestTemplate create a RestTemplate @Bean and use the @LoadBalanced qualifier.

[Warning]Warning

A RestTemplate bean is no longer created via auto configuration. It must be created by individual applications.

@Configuration
 public class MyConfiguration {
 
     @LoadBalanced
@@ -369,4 +369,23 @@ in downstream projects.  In addition, if you provide a bean of type spring.cloud.httpclientfactories.apache.enabled or spring.cloud.httpclientfactories.ok.enabled to
-false.
\ No newline at end of file +false.

2.9 Enabled Features

A /features actuator endpoint is provided by Commons. This endpoint returns features available on the classpath and if they are enabled or not. The information returned includes the feature type, name, version and vendor.

2.9.1 Feature types

There are two types of 'features': abstract and named.

Abstract features are features where an interface or abstract class is defined that an implementation creates, such as DiscoveryClient, LoadBalancerClient or LockService. The abstract class or interface is used to find a bean of that type in the context. The version displayed is bean.getClass().getPackage().getImplementationVersion().

Named features are features that don’t have a particular class they implement, such as "Circuit Breaker", "API Gateway", "Spring Cloud Bus", etc…​ These features require a name and a bean type.

2.9.2 Declaring features

Any module can declare any number of HasFeature beans. Some examples:

@Bean
+public HasFeatures commonsFeatures() {
+  return HasFeatures.abstractFeatures(DiscoveryClient.class, LoadBalancerClient.class);
+}
+
+@Bean
+public HasFeatures consulFeatures() {
+  return HasFeatures.namedFeatures(
+    new NamedFeature("Spring Cloud Bus", ConsulBusAutoConfiguration.class),
+    new NamedFeature("Circuit Breaker", HystrixCommandAspect.class));
+}
+
+@Bean
+HasFeatures localFeatures() {
+  return HasFeatures.builder()
+      .abstractFeature(Foo.class)
+      .namedFeature(new NamedFeature("Bar Feature", Bar.class))
+      .abstractFeature(Baz.class)
+      .build();
+}

Each of these beans should go in an appropriately guarded @Configuration.

\ No newline at end of file diff --git a/spring-cloud-commons.xml b/spring-cloud-commons.xml index b4a8c105..ff8eb050 100644 --- a/spring-cloud-commons.xml +++ b/spring-cloud-commons.xml @@ -341,7 +341,7 @@ on the classpath to cause the Spring Boot application to register with the servi
Health Indicator -Commons creates a Spring Boot HealthIndicator that DiscoveryClient implementations can participate in by implementing DiscoveryHealthIndicator. To disable the composite HealthIndicator set spring.cloud.discovery.client.composite-indicator.enabled=false. A generic 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. +Commons creates a Spring Boot HealthIndicator that DiscoveryClient implementations can participate in by implementing DiscoveryHealthIndicator. To disable the composite HealthIndicator set spring.cloud.discovery.client.composite-indicator.enabled=false. A generic 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.
@@ -369,7 +369,7 @@ public class MyConfiguration {
Service Registry Actuator Endpoint -A /service-registry actuator endpoint is provided by Commons. This endpoint relys on a Registration bean in the Spring Application Context. Calling /service-registry/instance-status via a GET will return the status of the Registration. A POST to the same endpoint with a String body will change the status of the current Registration to the new value. Please see the documentation of the ServiceRegistry implementation you are using for the allowed values for updating the status and the values retured for the status. +A /service-registry actuator endpoint is provided by Commons. This endpoint relies on a Registration bean in the Spring Application Context. Calling /service-registry via a GET will return the status of the Registration. A POST to the same endpoint with a JSON body will change the status of the current Registration to the new value. The JSON body has to include the status field with the preferred value. Please see the documentation of the ServiceRegistry implementation you are using for the allowed values for updating the status and the values returned for the status. For instance, Eureka’s supported statuses are UP, DOWN, OUT_OF_SERVICE and UNKNOWN.
@@ -604,5 +604,40 @@ You can also disable the creation of these beans by setting spring.cloud.httpclientfactories.apache.enabled or spring.cloud.httpclientfactories.ok.enabled to false.
+
+Enabled Features +A /features actuator endpoint is provided by Commons. This endpoint returns features available on the classpath and if they are enabled or not. The information returned includes the feature type, name, version and vendor. +
+Feature types +There are two types of 'features': abstract and named. +Abstract features are features where an interface or abstract class is defined that an implementation creates, such as DiscoveryClient, LoadBalancerClient or LockService. The abstract class or interface is used to find a bean of that type in the context. The version displayed is bean.getClass().getPackage().getImplementationVersion(). +Named features are features that don’t have a particular class they implement, such as "Circuit Breaker", "API Gateway", "Spring Cloud Bus", etc…​ These features require a name and a bean type. +
+
+Declaring features +Any module can declare any number of HasFeature beans. Some examples: +@Bean +public HasFeatures commonsFeatures() { + return HasFeatures.abstractFeatures(DiscoveryClient.class, LoadBalancerClient.class); +} + +@Bean +public HasFeatures consulFeatures() { + return HasFeatures.namedFeatures( + new NamedFeature("Spring Cloud Bus", ConsulBusAutoConfiguration.class), + new NamedFeature("Circuit Breaker", HystrixCommandAspect.class)); +} + +@Bean +HasFeatures localFeatures() { + return HasFeatures.builder() + .abstractFeature(Foo.class) + .namedFeature(new NamedFeature("Bar Feature", Bar.class)) + .abstractFeature(Baz.class) + .build(); +} +Each of these beans should go in an appropriately guarded @Configuration. +
+
\ No newline at end of file