From 4d9ec0bc14158af9296af6ee819520519749dc4e Mon Sep 17 00:00:00 2001 From: buildmaster Date: Sat, 29 Sep 2018 10:46:25 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- ...ing_cloud_commons_common_abstractions.html | 4 ++-- ..._context_application_context_services.html | 18 +++++++------- multi/multi_pr01.html | 2 +- multi/multi_spring-cloud-commons.html | 2 +- single/spring-cloud-commons.html | 22 ++++++++--------- spring-cloud-commons.html | 2 +- spring-cloud-commons.xml | 24 +++++++++---------- 7 files changed, 37 insertions(+), 37 deletions(-) diff --git a/multi/multi__spring_cloud_commons_common_abstractions.html b/multi/multi__spring_cloud_commons_common_abstractions.html index 079bfb94..ee48ddcb 100644 --- a/multi/multi__spring_cloud_commons_common_abstractions.html +++ b/multi/multi__spring_cloud_commons_common_abstractions.html @@ -1,6 +1,6 @@ - 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 (for example, discovery with Eureka or Consul).

2.1 @EnableDiscoveryClient

Spring Cloud Commons provides the @EnableDiscoveryClient annotation. + 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 (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. 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.

2.1.2 Ordering DiscoveryClient instances

DiscoveryClient interface extends Ordered. This is useful when using multiple discovery +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 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 @@ - 1. Spring Cloud Context: Application Context Services

1. Spring Cloud Context: Application Context Services
Prev   Next

1. Spring Cloud Context: Application Context Services

Spring Boot has an opinionated view of how to build an application with Spring. + 1. Spring Cloud Context: Application Context Services

1. Spring Cloud Context: Application Context Services
Prev   Next

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

1.1 The Bootstrap Application Context

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.

1.1 The Bootstrap Application Context

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

1.2 Application Context Hierarchies

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 PropertySourceLocators are found in the Bootstrap context and if they have non-empty properties, an optional CompositePropertySource appears 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 PropertySourceLocators are found in the Bootstrap context and if they have non-empty properties, an optional CompositePropertySource appears 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 the application.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.

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.

1.4 Overriding the Values of Remote Properties

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.

1.4 Overriding the Values of Remote Properties

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.

1.5 Customizing the Bootstrap Configuration

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]Warning

When adding custom BootstrapConfiguration, be careful that the classes you add are not @ComponentScanned by mistake into your “main” application context, where they might not be needed. +If you want to control the startup sequence, classes can be marked with an @Order annotation (the default order is last).

[Warning]Warning

When adding custom BootstrapConfiguration, be careful that the classes you add are not @ComponentScanned by mistake into your “main” application context, where they might not be needed. Use a separate package name for boot configuration classes and make sure that name is not already covered by your @ComponentScan or @SpringBootApplication annotated configuration classes.

The bootstrap process ends by injecting initializers into the main SpringApplication instance (which is the normal Spring Boot startup sequence, whether it is running as a standalone application or deployed in an application server). First, a bootstrap context is created from the classes found in spring.factories. Then, all @Beans of type ApplicationContextInitializer are added to the main SpringApplication before it is started.

1.6 Customizing the Bootstrap Property Sources

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 PropertySourceLocator to the bootstrap context (through spring.factories). diff --git a/multi/multi_pr01.html b/multi/multi_pr01.html index 488b1557..813f75b1 100644 --- a/multi/multi_pr01.html +++ b/multi/multi_pr01.html @@ -1,6 +1,6 @@ -

Prev   Next

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

Prev   Next

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 @@ - 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 + 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 a025397c..04a75d24 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.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. + 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. @@ -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.

[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, you can find the source code and issue trackers for 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 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.

1.1 The Bootstrap Application Context

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.

1.1 The Bootstrap Application Context

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. @@ -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 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).

1.2 Application Context Hierarchies

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 PropertySourceLocators are found in the Bootstrap context and if they have non-empty properties, an optional CompositePropertySource appears 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 PropertySourceLocators are found in the Bootstrap context and if they have non-empty properties, an optional CompositePropertySource appears 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 the application.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.

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. @@ -40,14 +40,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.

1.4 Overriding the Values of Remote Properties

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.

1.4 Overriding the Values of Remote Properties

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.

1.5 Customizing the Bootstrap Configuration

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]Warning

When adding custom BootstrapConfiguration, be careful that the classes you add are not @ComponentScanned by mistake into your “main” application context, where they might not be needed. +If you want to control the startup sequence, classes can be marked with an @Order annotation (the default order is last).

[Warning]Warning

When adding custom BootstrapConfiguration, be careful that the classes you add are not @ComponentScanned by mistake into your “main” application context, where they might not be needed. Use a separate package name for boot configuration classes and make sure that name is not already covered by your @ComponentScan or @SpringBootApplication annotated configuration classes.

The bootstrap process ends by injecting initializers into the main SpringApplication instance (which is the normal Spring Boot startup sequence, whether it is running as a standalone application or deployed in an application server). First, a bootstrap context is created from the classes found in spring.factories. Then, all @Beans of type ApplicationContextInitializer are added to the main SpringApplication before it is started.

1.6 Customizing the Bootstrap Property Sources

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 PropertySourceLocator to the bootstrap context (through spring.factories). @@ -95,7 +95,7 @@ It follows the same rules as the Config Server and has the same external configu 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.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. +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. 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. @@ -105,7 +105,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.

2.1.2 Ordering DiscoveryClient instances

DiscoveryClient interface extends Ordered. This is useful when using multiple discovery +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 diff --git a/spring-cloud-commons.html b/spring-cloud-commons.html index 0e14b8c0..8e1aa050 100644 --- a/spring-cloud-commons.html +++ b/spring-cloud-commons.html @@ -4,7 +4,7 @@ - + spring-cloud-commons