AOT Client Url from wrong profile

[lgklein]

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 #807??

[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...

[admintertar]

No, different environments need to compile different packages

[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 " T getTarget()" method I resolved the url parameter of the client interface (in the "Class<?> type;" attribute) and I forced the url class attribute, that made the magic happen and everything worked "correctly"...

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.

[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.

[sdeleuze]

See related spring-projects/spring-framework#29844 issue at Framework level, and related demo project.

[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...

[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?