From a9f3d4bc3c606965d8e3b34b615cad51b8190644 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Fri, 15 Jun 2018 17:56:12 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- ...ti__spring_cloud_context_application_context_services.html | 2 +- multi/multi_spring-cloud-commons.html | 2 +- single/spring-cloud-commons.html | 4 ++-- spring-cloud-commons.xml | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/multi/multi__spring_cloud_context_application_context_services.html b/multi/multi__spring_cloud_context_application_context_services.html index 2d01f451..f6755981 100644 --- a/multi/multi__spring_cloud_context_application_context_services.html +++ b/multi/multi__spring_cloud_context_application_context_services.html @@ -66,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.9 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 diff --git a/multi/multi_spring-cloud-commons.html b/multi/multi_spring-cloud-commons.html index 4574a755..7fead57c 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.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 23e00a3e..81762d11 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.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. @@ -72,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.9 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 diff --git a/spring-cloud-commons.xml b/spring-cloud-commons.xml index 3cb3c656..ba3f1ed8 100644 --- a/spring-cloud-commons.xml +++ b/spring-cloud-commons.xml @@ -179,7 +179,7 @@ For instance, a DataSource can have its maxPoolSize< 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. -

+
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.