cannot register to eureka server when spring.cloud.refresh.enabled is false

[vladgon]

mavenBom 'org.springframework.cloud:spring-cloud-dependencies:2023.0.0

According to

https://github.com/spring-cloud/spring-cloud-release/wiki/AOT-transformations-and-native-image-support and other documentation spring.cloud.refresh.enabled should be false when AOT compiling.

Application works fine when spring.cloud.refresh.enabled is true, but fails to register (registers with the port 0 ) when refresh is disabled

Server application.yaml

spring:
  application:
    name: demo-eureka-server

server:
  port: 8761

eureka:
  client:
    register-with-eureka: false
    fetch-registry: true

  dashboard:
    path: /dashboard

Client application.yaml

server:
  port: 0

spring:
  application:
    name: GreetingServer
  cloud:
    refresh:
      enabled: false
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka
  instance:
    preferIpAddress: true
    status-page-url-path: '/'
    instance-id: ${spring.application.name}:${random.long[0,90000000000000000]}
    leaseExpirationDurationInSeconds: 1
    lease-renewal-interval-in-seconds: 1

[OlgaMaciaszek]

Hello, @vladgon, thanks for reporting the issue. The premise for native images is the "closed world assumption", which for our purposes means that the application context and bean field values should not change at runtime, which is how the random port was being handled. Do you use the random port in your production applications?

[vladgon]

I would assume that the application deployed in the cloud environment should be assigned a random port number on start up then register itself wi the eureka server, providing the actual port number and then Eureka should redirect the request to the one of the many registered instances. Thanks, --Vladimir

…

On Jan 22, 2024, at 10:22 AM, Olga Maciaszek-Sharma ***@***.***> wrote: Hello, @vladgon <https://github.com/vladgon>, thanks for reporting the issue. The premise for native images is the "closed world assumption", which for our purposes means that the application context and bean field values should not change at runtime, which is how the random port was being handled. Do you use the random port in your production applications? — Reply to this email directly, view it on GitHub <#4235 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7BYM4DEZZR7UHBC3PRXFLYPZ74FAVCNFSM6AAAAABBAN5KM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBUGIZTGMJZHE>. You are receiving this because you were mentioned.

[OlgaMaciaszek]

We'll definitely be considering various implementation solutions. Please let us know if you use the random port feature in production or just for testing.

[vladgon]

We use random port in production but registering manually, would like to use spring data instead. --VladimirOn Jan 22, 2024, at 11:49 AM, Olga Maciaszek-Sharma ***@***.***> wrote: We'll definitely be considering various implementation solutions. Please let us know if you use the random port feature in production or just for testing. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[vladgon]

It is working fine when not compiling with AOT and the flag spring.cloud.refresh.enabled is true--VladimirOn Jan 22, 2024, at 12:01 PM, Vladimir Goncharov ***@***.***> wrote:We use random port in production but registering manually, would like to use spring data instead. --VladimirOn Jan 22, 2024, at 11:49 AM, Olga Maciaszek-Sharma ***@***.***> wrote: We'll definitely be considering various implementation solutions. Please let us know if you use the random port feature in production or just for testing. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>