You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if there's a builder bean for HTTP client (RestClient.Builder, WebClient.Builder, etc.) created by the user, it's used for creating the client used for communication with Eureka. The problem with this approach is that it's not readily visible for the users and we may end up using builder beans with a setup that was not intended by the users to be used for communicating with Eureka (for example, a @LoadBalanced RestClient.Builder). Consider switching to an approach where if there's a builder identified by the user for this specific purpose (for example, by a specific supplier function or interface), it's used, if not, we create our own and use available configurers/customisers on it to make sure the Boot-provided capabilities, such as metrics support are there.
Currently, if there's a builder bean for HTTP client (
RestClient.Builder
,WebClient.Builder
, etc.) created by the user, it's used for creating the client used for communication with Eureka. The problem with this approach is that it's not readily visible for the users and we may end up using builder beans with a setup that was not intended by the users to be used for communicating with Eureka (for example, a@LoadBalanced RestClient.Builder
). Consider switching to an approach where if there's a builder identified by the user for this specific purpose (for example, by a specific supplier function or interface), it's used, if not, we create our own and use available configurers/customisers on it to make sure the Boot-provided capabilities, such as metrics support are there.See:
The text was updated successfully, but these errors were encountered: