Disable RefreshScope in Config Server for AOT and native

[OlgaMaciaszek]

See https://github.com/spring-projects-experimental/spring-native/blob/main/spring-native/src/main/java/org/springframework/aot/beans/factory/config/NoOpScope.java

[habuma]

Trying to understand this issue (as I've been asked about it from MSFT): Why is this needed and is it in reference to Config Server itself or the clients of Config Server that might be natively compiled?

I've tested a natively-compiled client app with @RefreshScope and it works fine for the most part, with the only thing odd being the timing of when the refresh-scoped bean is reinstantiated after config changes and a POST to the refresh endpoint is sent. So, I'm just trying to gain better understanding of why disabling refresh scope is important and whether this is intended for the config server itself or its clients (or both).

[ryanjbaxter]

@OlgaMaciaszek is on vacation but I will try and answer

I believe it is for both.

The main problem (i believe) is that a configuration change could change the logic and which beans are enabled/disabled and that could break a native app. In general it seem like a bad idea to change the configuration of an application that is compiled natively.

[OlgaMaciaszek]

Thanks, @ryanjbaxter - that's right. Any config that can influence context creation should not change from build time to runtime, which is in keeping with the Graal Native images closed world assumption and the Spring AOT processing model does not support it. A lot of times with refresh scope enabled, natively compiled Spring Cloud applications won't even run. If they do, unexpected behaviour might occur, so we strongly discourage using it this way.

[habuma]

Understood and that's fair. So would this just disable the effects of @RefreshScope rendering the annotation inert? In other words, if the app is using @RefreshScope, it would still compile natively and run fine...it just wouldn't reinstantiate beans if the config changes, right?

[ryanjbaxter]

That would be my assumption yes. It would also be nice if we could render a warning somewhere stating that is the case.

[OlgaMaciaszek]

Sure, there's info in the docs and this issue is queued precisely to add better handling in apps.

[MatejNedic]

Hey @OlgaMaciaszek , sorry for pinging, but if I got this right this means that if any property changes, bean that already exists won't be reloaded with latest values and refreshed? (both for restart and hot reload?)
I fully understand the point regarding enable/disable bean and this makes total sense, but what if you want to change url of webclient?

I am currently writing native hints for Spring Cloud AWS as we have few integrations with spring.config.import and we support refresh on property change. From my perspective wouldn't it make sense to be able to refresh with restart option since you are only changing a property of bean such as url? Again, I fully see point for enable/disable since it needs to be provided on creation of executable.