16

Let me preface this by saying that I'm not using Spring Cloud Config directly, it is transitive via Spring Cloud Hystrix starter.

When only using @EnableHystrix, Spring Cloud also tries to locate a configuration server, expectedly unsuccessfully, since I'm not using one. The application works just fine, as far as I can tell, but the problem is in the status checks. Health shows DOWN because there is no config server.

Browsing the source of the project, I'd expect spring.cloud.config.enabled=false to disable this functionality chain, however this is not what I'm seeing.

After upgrading to 1.0.0.RC1 (which adds this property) and using @EnableCircuitBreaker:

{
    status: "DOWN",
    discovery: {
        status: "DOWN",
        discoveryClient: {
            status: "DOWN",
            error: "org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.cloud.client.discovery.DiscoveryClient] is defined"
        }
    },
    diskSpace: {
        status: "UP",
        free: 358479622144,
        threshold: 10485760
    },
    hystrix: {
        status: "UP"
    },
    configServer: {
        status: "DOWN",
        error: "org.springframework.web.client.ResourceAccessException: I/O error on GET request for "http: //localhost: 8888/bootstrap/default/master":Connection refused: connect; nested exception is java.net.ConnectException: Connection refused: connect"
    }
}

After checking the configprops endpoint, it seems that my properties are being overridden. Note that the parent has the configClient enabled.

parent: {
    configClientProperties: {
        prefix: "spring.cloud.config",
        properties: {
            password: null,
            discovery: {
                enabled: false,
                serviceId: "CONFIGSERVER"
            },
            name: "bootstrap",
            label: "master",
            env: "default",
            uri: "http://localhost:8888",
            enabled: true,
            failFast: false,
            username: null
        }
    }
},
configClientProperties: {
    prefix: "spring.cloud.config",
    properties: {
        password: null,
        discovery: {
            enabled: false,
            serviceId: "CONFIGSERVER"
        },
        name: "bootstrap",
        label: "master",
        env: "default",
        uri: "http://localhost:8888",
        enabled: false,
        failFast: false,
        username: null
    }
}

Any direction would be appreciated, if it seems I'm not doing this correctly.

bvulaj
  • 4,568
  • 4
  • 27
  • 40
  • What version of Spring Cloud are you using? – Dave Syer Dec 19 '14 at 16:05
  • I'm using 1.0.0.M3 of spring-cloud-starter-parent, which pulls in the same version of spring-cloud-starter-hystrix. I've updated my question with this information as well, thanks. – bvulaj Dec 19 '14 at 16:30
  • Try RC1 (just released). I think that flag was added (or extended) more recently. – Dave Syer Dec 19 '14 at 16:48
  • Thanks, @DaveSyer - I will give that a try and report back. – bvulaj Dec 19 '14 at 16:50
  • @DaveSyer - I've added my findings to the original post rather than the comments. I'm not sure if that change is for better or for worse in my case. I've also noted some parent properties that may be overriding my config. – bvulaj Dec 19 '14 at 19:01

5 Answers5

25

The config server is needed during bootstrap, and that's where the parent property sources come from. It looks like all you need to do is move your spring.cloud.config.enabled property to bootstrap.yml (or .properties).

Dave Syer
  • 52,217
  • 10
  • 149
  • 137
  • There seems to be some remaining cloud-config bleed over in the `DiscoveryClient`. `ConfigServer` seems to have been resolved, but `DiscoveryClient` is still showing as `DOWN` despite also adding `spring.cloud.config.discovery.enabled: false` to `bootstrap.properties` – bvulaj Dec 19 '14 at 20:17
  • That's the default anyway. And discovery is not connected to config, so I'd say that's another problem (we don't test much yet with different combinations of dependencies). Start a new post here or raise an issue in github for that? – Dave Syer Dec 19 '14 at 20:19
  • I'll do that. I'll mark this answered since it answers the original question. – bvulaj Dec 19 '14 at 20:20
  • Adding of `spring.cloud.config.enabled=false` (rather than `spring.config.enabled`) - to `bootstrap.properties` helped to eliminate `Fetching config from server at : http://localhost:8888` thanks – AlexK Sep 21 '18 at 07:34
  • Isn't the property removed now? https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1-Release-Notes – Akshay Jun 03 '20 at 12:28
12
  • You can put a bootstrap properties or yml to your resource direcotry or your applications directory and add spring.cloud.config.enabled=false. OR
  • You can disable spring cloud config server client by adding an environment variable: SPRING_CLOUD_CONFIG_ENABLED=false OR
  • Config server client can be disabled by adding a parameter to your app, if you pass the args to parameters to SpringApplication.run:

    public static void main(String[] args) throws Exception { SpringApplication.run(YourApplication.class, args); }

    and start the app by:

    java -jar yourapplication.jar --spring.cloud.config.enabled=false

Dániel Kis
  • 1,445
  • 21
  • 36
11

I had the same problem, I wanted to have the config server disabled (as we do not need it so far) but the property mentioned above is not correct for RC1 at least.

spring.cloud.enabled

Should be:

spring.cloud.config.enabled
MiguelPuyol
  • 409
  • 3
  • 10
6

I tried all of the above changes and still config client never stopped somehow.

The only way I was able to disable it by using following exclusion in my project's pom.xml file.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>
JMewada
  • 81
  • 1
  • 4
  • Exactly the sitation. None of the solutions out there work, but this exclusion method doesnt quite feel the best otpion. – Codeheda May 21 '21 at 17:06
1

Regarding the discovery service followup (looks like no other posts on that), setting spring.cloud.config.discovery.enabled: false worked for me, but only if it was set in bootstrap(yml/properties) and if I removed the @EnableDiscoveryClient annotation from my Application class. I guess this means one cannot use that annotation for any service where discovery will not be used at times.

jny
  • 7,433
  • 3
  • 29
  • 52
Eric Sword
  • 11
  • 1