I want to call my config-server named-base via my eureka. For that I need the eureka url in the default part to start the app.

But then if I want to provide different URLs for different profiles, I get an error.

Failed to bind properties under 'eureka.client.serviceurl.defaultzone' to java.lang.String:

    Property: eureka.client.serviceurl.defaultzone
    Value: http://other-host:8760/eureka/
    Origin: class path resource [application.yml] - 53:20
    Reason: org.springframework.boot.context.config.InactiveConfigDataAccessException: Inactive property source 'Config resource 'class path resource [application.yml]' via location 'optional:classpath:/' (document #2)' imported from location 'class path resource [application.yml]' cannot contain property 'eureka.client.serviceurl.defaultzone' [origin: class path resource [application.yml] - 51:20]

Action:

Update your application's configuration

this is my application.yml

spring:
  application:
    name: app
  cloud:
    config:
      discovery:
        enabled: true
        service-id: common-cloud-config
      fail-fast: true
      retry:
        max-attempts: 5

eureka:
  client:
    enabled: true
    serviceUrl:
      defaultZone: http://localhost:8760/eureka/
  instance:
    leaseRenewalIntervalInSeconds: 10
    prefer-ip-address: false
    hostname: 127.0.0.1

application:
  value: app-default

security:
  value: app-sec-default

---

spring:
  config:
    activate:
      on-profile: dev
    import: "configserver:"

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8760/eureka/

---

spring:
  config:
    activate:
      on-profile: qa
    import: "configserver:"

eureka:
  client:
    serviceUrl:
      defaultZone: http://other-host:8760/eureka/ # this is line 53 in the exception

before the spring boot 2.4 update, I did this in my bootstrap.yml without any problems....

does my file have any mistakes or is this just not possible any more??

Comment From: wilkinsona

Thanks for the report, @m1well. What are the active profiles when the failure occurs? I'm guessing that dev is active but I'd like to know for sure.

Comment From: m1well

I tried it with both: dev and qa - and both didn't start.

I can only start the app with one eureka url in the default section. but that doesn't fit to my business needs.

a also can start the app without config-server, having multiple eureka urls. but I also need the config-server name based via eureka. but that doesn't work currently (with the posted config)

Comment From: wilkinsona

@philwebb and I looked at this yesterday and we came to the conclusion that there's a chicken-and-egg problem in Spring Cloud that we cannot address in Spring Boot. Eureka can be used to discover the config server and the config server can also be used to configure the location of Eureka.

While Spring Boot is gathering all of the config data, it does not allow any profile-specific properties to be used. This provides a complete view of all of the potential config data before the active profiles are applied, ensuring that a profile's configuration is applied consistently and in full.

In the example above, config server discovery is enabled. As things stand, this requires Spring Cloud to resolve eureka.client.serviceUrl.defaultZone while gathering config data. As described above, the use of profile-specific properties at this point is prohibited. Spring Boot deliberately does not fall back to the non-profile-specific configuration for eureka.client.serviceUrl.defaultZone as we feel that it would be confusing if the qa or dev profile was deemed to be active once all of the config data has been gathered and the remainder of their profile-specific properties were then used.

@spencergibb recently made some changes to improve retry configuration with config server. We think it may be possible to do something similar in Spring Cloud for this case too.

Comment From: pmahony893

@wilkinsona

We think it may be possible to do something similar in Spring Cloud for this case too.

Did anything ever happen with this? It doesn't seem that unusual (to me, at least) to want different discovery-first configs to be applied in different situations, which profiles would otherwise feel like a natural fit for. Is there any workaround?

Comment From: wilkinsona

I'm not sure as It would be a Spring Cloud change and I'm not on the Spring Cloud team. @spencergibb is the person to ask.