From 5c5e39fce346206d2027907489fa283df3ea9eb1 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Thu, 7 Jun 2018 18:32:34 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- ...g_cloud_context_application_context_services.html | 10 ++++++---- multi/multi_spring-cloud-commons.html | 2 +- single/spring-cloud-commons.html | 12 +++++++----- spring-cloud-commons.xml | 6 ++++++ 4 files changed, 20 insertions(+), 10 deletions(-) diff --git a/multi/multi__spring_cloud_context_application_context_services.html b/multi/multi__spring_cloud_context_application_context_services.html index 69b4156b..2d01f451 100644 --- a/multi/multi__spring_cloud_context_application_context_services.html +++ b/multi/multi__spring_cloud_context_application_context_services.html @@ -55,7 +55,9 @@ For instance, you can insert additional properties from a different server or fr } }

The Environment that is passed in is the one for the ApplicationContext about to be created — in other words, the one for which we supply additional property sources for. -It already has its normal Spring Boot-provided property sources, so you can use those to locate a property source specific to this Environment (for example, by keying it on spring.application.name, as is done in the default Spring Cloud Config Server property source locator).

If you create a jar with this class in it and then add a META-INF/spring.factories containing the following, the customProperty PropertySource appears in any application that includes that jar on its classpath:

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

1.7 Environment Changes

The application listens for an EnvironmentChangeEvent and reacts to the change in a couple of standard ways (additional ApplicationListeners can be added as @Beans by the user in the normal way). +It already has its normal Spring Boot-provided property sources, so you can use those to locate a property source specific to this Environment (for example, by keying it on spring.application.name, as is done in the default Spring Cloud Config Server property source locator).

If you create a jar with this class in it and then add a META-INF/spring.factories containing the following, the customProperty PropertySource appears in any application that includes that jar on its classpath:

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

1.7 Logging Configuration

If you are going to use Spring Boot to configure log settings than +you should place this configuration in `bootstrap.[yml | properties] +if you would like it to apply to all events.

1.8 Environment Changes

The application listens for an EnvironmentChangeEvent and reacts to the change in a couple of standard ways (additional ApplicationListeners can be added as @Beans by the user in the normal way). When an EnvironmentChangeEvent is observed, it has a list of key values that have changed, and the application uses those to:

  • Re-bind any @ConfigurationProperties beans in the context
  • Set the logger levels for any properties in logging.level.*

Note that the Config Client does not, by default, poll for changes in the Environment. Generally, we would not recommend that approach for detecting changes (although you could set it up with a @Scheduled annotation). @@ -64,7 +66,7 @@ Note that those APIs are public and part of core Spring). You can verify that the changes are bound to @ConfigurationProperties beans by visiting the /configprops endpoint (a 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.

1.8 Refresh Scope

When there is a configuration change, a Spring @Bean that is marked as @RefreshScope gets special treatment. +To address those concerns, we have @RefreshScope.

1.9 Refresh Scope

When there is a configuration change, a Spring @Bean that is marked as @RefreshScope gets special treatment. This feature addresses the problem of stateful beans that only get their configuration injected when they are initialized. For instance, if a DataSource has open connections when the database URL is changed via the Environment, you probably want the holders of those connections to be able to complete what they are doing. Then, the next time something borrows a connection from the pool, it gets one with the new URL.

Sometimes, it might even be mandatory to apply the @RefreshScope @@ -81,9 +83,9 @@ To refresh an individual bean by name, there is also a ref include: refresh

[Note]Note

@RefreshScope works (technically) on an @Configuration class, but it might lead to surprising behavior. For example, it does not mean that all the @Beans defined in that class are themselves in @RefreshScope. Specifically, anything that depends on those beans cannot rely on them being updated when a refresh is initiated, unless it is itself in @RefreshScope. -In that case, it is rebuilt on a refresh and its dependencies are re-injected. At that point, they are re-initialized from the refreshed @Configuration).

1.9 Encryption and Decryption

Spring Cloud has an Environment pre-processor for decrypting property values locally. +In that case, it is rebuilt on a refresh and its dependencies are re-injected. At that point, they are re-initialized from the refreshed @Configuration).

1.10 Encryption and Decryption

Spring Cloud has an Environment pre-processor for decrypting property values locally. It follows the same rules as the Config Server and has the same external configuration through encrypt.*. Thus, you can use encrypted values in the form of {cipher}* and, as long as there is a valid key, they are decrypted before the main application context gets the Environment settings. To use the encryption 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 get an exception due to "Illegal key size" and you use 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 the files into the JDK/jre/lib/security folder for whichever version of JRE/JDK x64/x86 you use.

1.10 Endpoints

For a Spring Boot Actuator application, some additional management endpoints are available. You can use:

  • POST to /actuator/env to update the Environment and rebind @ConfigurationProperties and log levels.
  • /actuator/refresh to re-load the boot strap context and refresh the @RefreshScope beans.
  • /actuator/restart to close the ApplicationContext and restart it (disabled by default).
  • /actuator/pause and /actuator/resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext).
[Note]Note

If you disable the /actuator/restart endpoint then the /actuator/pause and /actuator/resume endpoints +See the following links for more information:

Extract the files into the JDK/jre/lib/security folder for whichever version of JRE/JDK x64/x86 you use.

1.11 Endpoints

For a Spring Boot Actuator application, some additional management endpoints are available. You can use:

  • POST to /actuator/env to update the Environment and rebind @ConfigurationProperties and log levels.
  • /actuator/refresh to re-load the boot strap context and refresh the @RefreshScope beans.
  • /actuator/restart to close the ApplicationContext and restart it (disabled by default).
  • /actuator/pause and /actuator/resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext).
[Note]Note

If you disable the /actuator/restart endpoint then the /actuator/pause and /actuator/resume endpoints will also be disabled since they are just a special case of /actuator/restart.

Prev   Next
 Home 2. Spring Cloud Commons: Common Abstractions
\ No newline at end of file diff --git a/multi/multi_spring-cloud-commons.html b/multi/multi_spring-cloud-commons.html index 04b3dd77..4574a755 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
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.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 2dd3f1ea..23e00a3e 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
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.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. @@ -61,7 +61,9 @@ For instance, you can insert additional properties from a different server or fr } }

The Environment that is passed in is the one for the ApplicationContext about to be created — in other words, the one for which we supply additional property sources for. -It already has its normal Spring Boot-provided property sources, so you can use those to locate a property source specific to this Environment (for example, by keying it on spring.application.name, as is done in the default Spring Cloud Config Server property source locator).

If you create a jar with this class in it and then add a META-INF/spring.factories containing the following, the customProperty PropertySource appears in any application that includes that jar on its classpath:

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

1.7 Environment Changes

The application listens for an EnvironmentChangeEvent and reacts to the change in a couple of standard ways (additional ApplicationListeners can be added as @Beans by the user in the normal way). +It already has its normal Spring Boot-provided property sources, so you can use those to locate a property source specific to this Environment (for example, by keying it on spring.application.name, as is done in the default Spring Cloud Config Server property source locator).

If you create a jar with this class in it and then add a META-INF/spring.factories containing the following, the customProperty PropertySource appears in any application that includes that jar on its classpath:

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

1.7 Logging Configuration

If you are going to use Spring Boot to configure log settings than +you should place this configuration in `bootstrap.[yml | properties] +if you would like it to apply to all events.

1.8 Environment Changes

The application listens for an EnvironmentChangeEvent and reacts to the change in a couple of standard ways (additional ApplicationListeners can be added as @Beans by the user in the normal way). When an EnvironmentChangeEvent is observed, it has a list of key values that have changed, and the application uses those to:

  • Re-bind any @ConfigurationProperties beans in the context
  • Set the logger levels for any properties in logging.level.*

Note that the Config Client does not, by default, poll for changes in the Environment. Generally, we would not recommend that approach for detecting changes (although you could set it up with a @Scheduled annotation). @@ -70,7 +72,7 @@ Note that those APIs are public and part of core Spring). You can verify that the changes are bound to @ConfigurationProperties beans by visiting the /configprops endpoint (a 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.

1.8 Refresh Scope

When there is a configuration change, a Spring @Bean that is marked as @RefreshScope gets special treatment. +To address those concerns, we have @RefreshScope.

1.9 Refresh Scope

When there is a configuration change, a Spring @Bean that is marked as @RefreshScope gets special treatment. This feature addresses the problem of stateful beans that only get their configuration injected when they are initialized. For instance, if a DataSource has open connections when the database URL is changed via the Environment, you probably want the holders of those connections to be able to complete what they are doing. Then, the next time something borrows a connection from the pool, it gets one with the new URL.

Sometimes, it might even be mandatory to apply the @RefreshScope @@ -87,11 +89,11 @@ To refresh an individual bean by name, there is also a ref include: refresh

[Note]Note

@RefreshScope works (technically) on an @Configuration class, but it might lead to surprising behavior. For example, it does not mean that all the @Beans defined in that class are themselves in @RefreshScope. Specifically, anything that depends on those beans cannot rely on them being updated when a refresh is initiated, unless it is itself in @RefreshScope. -In that case, it is rebuilt on a refresh and its dependencies are re-injected. At that point, they are re-initialized from the refreshed @Configuration).

1.9 Encryption and Decryption

Spring Cloud has an Environment pre-processor for decrypting property values locally. +In that case, it is rebuilt on a refresh and its dependencies are re-injected. At that point, they are re-initialized from the refreshed @Configuration).

1.10 Encryption and Decryption

Spring Cloud has an Environment pre-processor for decrypting property values locally. It follows the same rules as the Config Server and has the same external configuration through encrypt.*. Thus, you can use encrypted values in the form of {cipher}* and, as long as there is a valid key, they are decrypted before the main application context gets the Environment settings. To use the encryption 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 get an exception due to "Illegal key size" and you use 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 the files into the JDK/jre/lib/security folder for whichever version of JRE/JDK x64/x86 you use.

1.10 Endpoints

For a Spring Boot Actuator application, some additional management endpoints are available. You can use:

  • POST to /actuator/env to update the Environment and rebind @ConfigurationProperties and log levels.
  • /actuator/refresh to re-load the boot strap context and refresh the @RefreshScope beans.
  • /actuator/restart to close the ApplicationContext and restart it (disabled by default).
  • /actuator/pause and /actuator/resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext).
[Note]Note

If you disable the /actuator/restart endpoint then the /actuator/pause and /actuator/resume endpoints +See the following links for more information:

Extract the files into the JDK/jre/lib/security folder for whichever version of JRE/JDK x64/x86 you use.

1.11 Endpoints

For a Spring Boot Actuator application, some additional management endpoints are available. You can use:

  • POST to /actuator/env to update the Environment and rebind @ConfigurationProperties and log levels.
  • /actuator/refresh to re-load the boot strap context and refresh the @RefreshScope beans.
  • /actuator/restart to close the ApplicationContext and restart it (disabled by default).
  • /actuator/pause and /actuator/resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext).
[Note]Note

If you disable the /actuator/restart endpoint then the /actuator/pause and /actuator/resume endpoints will also be disabled since they are just a special case of /actuator/restart.

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 (for example, discovery with Eureka or Consul).

2.1 @EnableDiscoveryClient

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. diff --git a/spring-cloud-commons.xml b/spring-cloud-commons.xml index ea44aee6..4c13ee75 100644 --- a/spring-cloud-commons.xml +++ b/spring-cloud-commons.xml @@ -150,6 +150,12 @@ It already has its normal Spring Boot-provided property sources, so you can use If you create a jar with this class in it and then add a META-INF/spring.factories containing the following, the customProperty PropertySource appears in any application that includes that jar on its classpath: org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator +

+Logging Configuration +If you are going to use Spring Boot to configure log settings than +you should place this configuration in `bootstrap.[yml | properties] +if you would like it to apply to all events. +
Environment Changes The application listens for an EnvironmentChangeEvent and reacts to the change in a couple of standard ways (additional ApplicationListeners can be added as @Beans by the user in the normal way).