I was testing the new version 4.0 with AOT and it seems that there is a bug with multiple profiles (dev, hom, local, etc) in url resolution via parameter.
I have 3 profiles:
application-local.properties: url.int=https://des-sts-int
application-dev.properties: url.int=https://des-sts-int
application-hom.properties: url.int=https://hom-sts-int
a FeignClient:
@FeignClient(name = "urlIntCliente", url = "${url.int}")
public interface UrlIntCliente {
...}
@SpringBootApplication
@EnableFeignClients(clients = UrlIntCliente.class)
public class App {
@Autowired
private UrlIntCliente clientSts;
public static void main(final String[] args) {
final SpringApplication app = new SpringApplication(App.class);
app.run(args);
}
@Bean
ApplicationRunner applicationRunner(@Value("${url.int}") final String url) {
return args -> { //
System.out.println("FEIGN URL = " + url);
System.out.println(clientSts);
};
}
}
I build application with: mvn spring-boot:build-image -Pnative (with spring_profiles_active=local on env)
Start app using spring_profiles_active=hom on env)
The result on log:
The following 1 profile is active: "hom"
FEIGN URL = https://hom-sts-int HardCodedTarget(type=UrlIntCliente, name=urlIntCliente, url=https://des-sts-int)
Apparently it keeps what was generated in the build and doesn't update with startup information when a profile is selected... @OlgaMaciaszek Is this a bug or i'm doing something wrong here?
Same root problem of https://github.com/spring-cloud/spring-cloud-openfeign/issues/807??
Comment From: lgklein
Just to clarify, what I'm trying to do is not have the client's properties refreshable (which the documentation makes clear is not possible), it's having them static with whatever is loaded from the profile chosen at app start.
Restricting the use of profiles seems a little too drastic, doesn't it?
Aside from, probably, restrict the use of AOT for the overwhelming majority of real-life applications that use openfeign...
Comment From: admintertar
No, different environments need to compile different packages
Comment From: lgklein
No, different environments need to compile different packages
Well, unfortunately this borders on unacceptable for scenarios with well-structured CICD, the operational cost (Mainly for those who have the CICD in a public cloud and pay for build time) and time that this would add for multi-tenant cases...
It still seems strange to me that most modules that "change" between environments accept the profile and openfeing does not (spring data, spring cassandra, spring redis, spring kafka, spring grpc, and probably many others that I haven't tried yet...)
Well, as in my scenario what I need to change from environment to environment is just the url, I overwrote the FeignClientFactoryBean, in the "
I imagine that most of the client attributes should not be reprocessed at app start, but the URL is one that definitely should...
Hopefully it will be treated as a bug/improvement and some next version will bring this corrected/implemented.
Comment From: OlgaMaciaszek
Hello, @lgklein this is in keeping with the native image "closed-world" assumption. There's some ongoing discussion in the team on whether it would be advantageous to allow marking certain properties as runtime-specific and acquiring their values then in the future (CC @snicoll, @sdeleuze), but this would have to be limited to ones that do not influence beans and context creation only.
Comment From: sdeleuze
See related spring-projects/spring-framework#29844 issue at Framework level, and related demo project.
Comment From: lgklein
@OlgaMaciaszek ty for response!
@sdeleuze Sorry, but I think I misunderstood... Probably because I don't know in great detail how it works... So if I say something very wrong here I'm sorry...
Shouldn't it be the module's responsibility to define this? The framework always pulls the bean definitions for the build and that seems ok for AOT.
But as I exemplified, we have some beans from some modules that NEED to have configuration parameters per environment, parameters that don't change the behavior of the bean itself, of course... I can imagine the kind of problem that could happen if the behavior of beans could be changed between build and runtime. All the "springs datas" that I tested in AOT reload the url/user/pass on runtime for example, the same for spring kafka, spring grpc, etc...
Shouldn't it be, at the very least, a shared responsibility between the framework and the module? Framework to detail well what can or cannot be changed in general, and the module to guarantee the specificity of your rule and guarantee its simplified use?
In the case of Openfeign, the URL seems to me to be the only parameter that should be evaluated at runtime to make the use and management of environments MUCH easier...
Comment From: sdeleuze
@OlgaMaciaszek Given the behavior described in the issue and demo application linked above, have you identified why the simple string customization does not work here?
Comment From: OlgaMaciaszek
@lgklein @sdeleuze with the way it's directly handled with the URL resolved and set while creating a FactoryBean and a Feign HardCodedTarget with that URL set. However, I can modify it in order to resolve it directly in the Feign Target each time rechecking from properties, which would be slightly less efficient, but would do the trick. Have drafted a quick POC - should be able to finish it up and get it into 4.0.2.