Properties eureka.client.enabled and spring.cloud.consul.discovery.enabled have no effects without bootstrap

[xhuy-le]

Describe the bug
I try to locate the config server by using a discovery service client (Eureka or Consul). When only one artifact spring-cloud-starter-netflix-eureka-client or spring-cloud-starter-consul-discovery is present in the classpath, the app locates successfully the config server, regardless the value of eureka.client.enabled and spring.cloud.consul.discovery.enabled (check out the main or feature/register_with_consul branches of the sample project).

When both artifacts spring-cloud-starter-netflix-eureka-client or spring-cloud-starter-consul-discovery are present in the classpath, the Consul discovery client is always used by the app to locate the config server, regardless the value of eureka.client.enabled and spring.cloud.consul.discovery.enabled (check out the feature/without_bootstrap branch of the sample project).

On the other hand, it works as expected when I use the Config First Bootstrap with Discovery Lookup First enabled (feature/with_bootstrap branch of the sample project).

Sample
Here is the link to the sample project https://github.com/xhuy-le/spring-cloud-discovery-client-issues.

[ryanjbaxter]

When I try the branch feature/without_bootstrap it uses the Eureka DiscoveryClient and not the Consul DiscoveryClient...the configuration seems to work as expected.

[xhuy-le]

Hello,

Thank you very much for your response.

I've just pushed a new commit to feature/without_bootstrap branch to display registered discovery clients. Here is the result in the log file :

> Task :bootRun

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.7.0)

2022-06-01 13:29:09.321  INFO 3960 --- [           main] o.s.c.d.appdemo.AppDemoApplication       : Starting AppDemoApplication using Java 17.0.3 on idlv-xhle-debian with PID 3960 (/home/xhle/various/spring-cloud-issues/discovery-client/app-demo/build/classes/java/main started by xhle in /home/xhle/various/spring-cloud-issues/discovery-client/app-demo)
2022-06-01 13:29:09.324  INFO 3960 --- [           main] o.s.c.d.appdemo.AppDemoApplication       : No active profile set, falling back to 1 default profile: "default"
2022-06-01 13:29:10.000  INFO 3960 --- [           main] o.s.cloud.context.scope.GenericScope     : BeanFactory id=ddfc6d61-f394-3453-a743-2abeb5d5abde
2022-06-01 13:29:10.222  INFO 3960 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2022-06-01 13:29:10.229  INFO 3960 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2022-06-01 13:29:10.230  INFO 3960 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.63]
2022-06-01 13:29:10.286  INFO 3960 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2022-06-01 13:29:10.286  INFO 3960 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 907 ms
org.springframework.cloud.client.discovery.composite.CompositeDiscoveryClient@2721044
org.springframework.cloud.client.discovery.simple.SimpleDiscoveryClient@2ecf5915
org.springframework.cloud.netflix.eureka.EurekaDiscoveryClient@53e76c11
org.springframework.cloud.consul.discovery.ConsulDiscoveryClient@42cc183e

The Consul discovery client is registered in the Spring context despite spring.cloud.consul.discovery.enable=false, alongside with Eureka client. So I think the behaviour is not deterministic. In some environments (like yours) the config server picks up the Eureka client and everything is fine. In some other environments (like mines), the config server picks up the wrong Consul discovery client and the app fails to start.

For information, I made my tests on Debian Bullseye and Ubuntu Jammy, Java 17 and Gradle 7.4.2.

You could also check out the branch feature/register_with_consul, where the Eureka and Consul client are both disabled. And Spring still uses Consul client to locate the config server.

Huy