When we added spring-cloud-starter-consul-all as a build dependency, it automatically pulled all the necessary components to enable Consul functionality for our application. We automatically got the spring-cloud-consul-binder, spring-cloud-consul-core, spring-cloud-consul-config, and spring-cloud-consul-discovery artifacts added to our classpath. Let's take a look at the them:

• spring-cloud-consul-core: This artifact provides base autoconfiguration to expose generic ConsulProperties, as well as the ConsulClient initialization and setting of the /consul management endpoint, if the Spring Boot Actuator functionality is enabled.
• spring-cloud-consul-config: This provides the ConsulPropertySourceLocator implementation, used during Bootstrap, to configure the ConsulPropertySource bean, which allows remote configuration consumption from the Consul key/value store. It also sets up a ConfigWatch change observer, which fires RefreshEvent to the application context, if a configuration key value changes in Consul key/value store while the application is running. This allows for a possible configuration properties reload without having to redeploy and restart the application.
• spring-cloud-consul-discovery: This provides all the functionality and implementations needed for service discovery, service registration, and service invocation.
• spring-cloud-consul-binder: This provides integration of Consul event functionality with Spring Cloud Stream Framework, enabling it to send and receive events from Consul and respond to them within the application. While outside of the scope of this chapter, more information can be obtained from http://cloud.spring.io/spring-cloud-stream/.

While addition of spring-cloud-consul-config to the classpath will automatically register ConsulPropertySource, it is not so for the spring-cloud-consul-discovery module. The service discovery functionality is more intrusive and thus requires an additional step of acknowledgement from the developers to indicate that it is indeed wanted. This is accomplished by adding the @EnableDiscoveryClient annotation to the main application class; in our case it is BookPubApplication.

Once the @EnableDiscoveryClient annotation is added, Spring Cloud (EnableDiscoveryClientImportSelector class from the spring-cloud-commons module, to be more precise) scans all spring.factories files for the presence of the org.springframework.cloud.client.discovery.EnableDiscoveryClient key, and loads all the associated configurations into the main application context. If we look inside the spring.factories file located in the spring-cloud-consul-discovery JAR under the META-INF/ directory, we will see the following entry:

# Discovery Client Configuration 
org.springframework.cloud.client.discovery.EnableDiscoveryClient= 
org.springframework.cloud.consul.discovery.ConsulDiscoveryClientConfiguration

This tells us that when the discovery client is enabled, ConsulDiscoveryClientConfiguration will be consumed and all of its defining beans will be added to the application context.

A similar approach can be used if a custom service discovery mechanism is being used. One will need to create a custom configuration class, exposing a custom implementation of the DiscoveryClient interface, and configure it in the spring.factories file bundled within the archive. Once that JAR gets loaded, the configuration will be automatically consumed if discovery client functionality is enabled.