Before we dive under the hood of how things work, let's review the changes that we have made to our project. The first step was to enhance the build.gradle build configuration by importing a Bill of Material (BOM) declaration for a Spring Cloud release train—mavenBom 'org.springframework.cloud:spring-cloud-dependencies: Finchley.BUILD-SNAPSHOT'. While we could have selectively imported explicitly-defined versions of the spring-cloud-context and spring-cloud-commons libraries, by relying on a packaged BOM, we are sure that we will be using the correct versions of different artifacts that have been tested for compatibility with each other.

We start by adding dependencies on the spring-cloud-context and spring-cloud-commons libraries, to illustrate the basic common facilities Spring Cloud provides, before diving into a specific starter integration such as spring-cloud-netflix or spring-cloud-consul. Those basic libraries provide a foundation of interfaces and common functionality that is being used to build upon in all the different cloud-specific integrations. Here is what their purpose is:

• spring-cloud-commons: This provides a collection of shared common interfaces and base classes that define the notions of service discovery, service routing, load balancing, circuit breaking, feature capabilities, and some basic configuration. For example, this is the library that autoconfigures the environment with the springCloudClientHostInfo property source.
• spring-cloud-context: This is the base foundation that is responsible for bootstrapping and configuring the various integrations, such as a specific implementation of service discovery like Consul, or a specific implementation of circuit breaker like Hystrix. This is achieved by creating an isolated Bootstrap application context, which is responsible for loading and configuring all the components before the main application is started.

Bootstrap application context gets created early on in the application start cycle and it is configured by a separate file—bootstrap.properties (a YAML variant is also supported). Since it is very typical for an application running in the cloud to rely on many external sources of configuration, service lookup, and so on, the purpose of the Bootstrap context is to configure those functions and obtain all of the necessary configuration from outside.

To clearly separate application configuration from Bootstrap, we put things that describe the application, or configure external configs, or other environmental variants like where to call for service discovery, into bootstrap.properties instead of application.properties. In our example, we have placed spring.application.name config into bootstrap.properties, because that information will be needed during the Bootstrap phase; it could be used to look up configuration from a remote config store.

Since Bootstrap application context is indeed a real Spring application context, there exists a parent-child relationship between the two, where Bootstrap application context becomes the parent of the Spring Boot application context. This means that all the beans and the property sources defined in the Bootstrap context become available for consumption from within the application context as well.

When Spring Cloud is added to the application, it automatically provides the integration framework for specific Spring Cloud modules, like Spring Cloud Consul, to be plugged in via the use of the by now well-known spring.factories configuration declarations. The annotations provided inside spring-cloud-commons, namely @SpringCloudApplication, @EnableDiscoveryClient, @EnableCircuitBreaker, and the @BootstrapConfiguraion and PropertySourceLocator interfaces provided by the spring-cloud-context library, are designed to define the integration points to be used to self-configure specific components such as discovery clients like Consul, circuit breakers like Hystrix, or remote configuration sources like ZooKeeper.

Let's examine those in detail:

• @SpringCloudApplication: This annotation is like @SpringBootApplication, meta-annotation in nature, except it also wraps the @EnableDiscoveryClient and @EnableCircuitBreaker annotations in addition to also being meta-annotated with @SpringBootApplication. It is a good idea to use this annotation when you want to enable both the discovery client and the circuit breaker functionality in your application.
• @EnableDiscoveryClient: This annotation is used to indicate that Spring Cloud should initialize the provided discovery client for service registry, depending on the included integration library, such as Consul, Eureka, ZooKeeper, and so on.
• @EnableCircuitBreaker: This annotation is used to indicate that Spring Cloud should initialize the circuit breaker capabilities, based on the specific dependency of the integration library, such as Hystrix.
• PropertySourceLocator: This is used by the integration libraries to implement specific functionality of how to extract remote configuration from the provided datastore. Each integration module, providing ability to load remote configuration, would register an implementing bean of this type that exposes an implementation of PropertySource that is backed by the integration.
• @BootstrapConfiguration: This annotation is like the @ManagementContextConfiguration annotation, and is (mostly) a marker annotation geared to identify the key inside the spring.factories descriptor to indicate which configuration classes should be loaded during the Spring Cloud Bootstrap process and be part of the Bootstrap application context. Those configurations are read by BootstrapApplicationListener during startup and initialize the specified configurations. Typically, this is where the configuration classes, which define and expose PropertySourceLocator—implementing beans, are configured.