REST Client Config - Limitations of ConfigRoot `RestClientsConfig`

Describe the bug

We are seeing several issues with the REST Client Config move to the RestClientsConfig ConfigRoot added in https://github.com/quarkusio/quarkus/pull/17220.

Related issues:

• https://github.com/quarkusio/quarkus/issues/21341
• https://github.com/quarkusio/quarkus/issues/21336
• https://github.com/quarkusio/quarkus/issues/21332
• https://github.com/quarkusio/quarkus/issues/21345

One of the main issues seems to be the expectation that the REST Client Config (or at least the URL) can be dynamically changed during runtime by just changing the configuration.

Another issue is the way that RestClientConfig is mapped. The use of public Map<String, RestClientConfig> configs; implies that named configuration (in this case the resource) is added by iterating the Config#getPropertyNames. This is usually ok because for most cases we are not aware of the named configuration and this is the only way to retrieve them. In the particular case of REST Clients, the named configuration is known at build time, but we ignore it and fill in the Map with getPropertyNames ignoring that some Config Sources like Vault do not provide their property names.

[radcortez]

I think we can try to compromise here a bit. It should be possible to override the default QuarkusRestClientBuilder to dynamically read the configuration, so it is not required to change all the code to use the REST Client builder directly.

Can you please give me an example of what the code would look like?

It depends on how you want to code it but, dynamic config retrieval could be done here by entending this class and overriding the build method.

https://github.com/quarkusio/quarkus/blob/1e517c8cc58a743e879f437821d1cfd9c0c79e0a/extensions/resteasy-classic/rest-client/runtime/src/main/java/io/quarkus/restclient/runtime/QuarkusRestClientBuilder.java#L234

Registration is just a static call to org.eclipse.microprofile.rest.client.spi.RestClientBuilderResolver#setInstance to add a new Resolver for the new Builder. In this way, you are not required to have producer methods to change any of the code where REST Clients are used.

Alternatively, you can modify at your own risk the values of RestClientsConfig 😃

[franden]

Which is why I metioned above that we should provide some way for the values in application.properties to be made available to the Builder API without requiring users to write this boilterplate.

Ahhh. Got it. Thanks