-
Notifications
You must be signed in to change notification settings - Fork 168
Simplify OpAmp client api #2408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,42 @@ | ||
| /* | ||
| * Copyright The OpenTelemetry Authors | ||
| * SPDX-License-Identifier: Apache-2.0 | ||
| */ | ||
|
|
||
| package io.opentelemetry.opamp.client.internal; | ||
|
|
||
| import io.opentelemetry.opamp.client.OpampClientBuilder; | ||
| import io.opentelemetry.opamp.client.internal.request.service.RequestService; | ||
| import java.net.URI; | ||
| import java.util.function.BiConsumer; | ||
| import java.util.function.Function; | ||
| import javax.annotation.Nullable; | ||
|
|
||
| /** | ||
| * This class is internal and experimental. Its APIs are unstable and can change at any time. Its | ||
| * APIs (or a version of them) may be promoted to the public stable API in the future, but no | ||
| * guarantees are made. | ||
| */ | ||
| public final class Experimental { | ||
|
|
||
| @Nullable | ||
| private static volatile BiConsumer<OpampClientBuilder, Function<URI, RequestService>> | ||
| setServiceFactory; | ||
|
|
||
| /** | ||
| * Sets factory function for creating {@link RequestService} instances form a given server URI. | ||
| */ | ||
| public static void setServiceFactory( | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm not too worried about the internal package, as this lib is not stable anyway, though I currently need to pass a custom service with a customized okhttp client instance to intercept all the requests, so having to rely on statics for this factory and within an experimental scope seems a bit unnecessarily inconvenient to me, given the current status of this lib. What if this setter is moved into the builder and it's called from within the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the pattern we are using in the instrumentation repository to introduce experimental functionality. Vast majority of users shouldn't really need the requestService = HttpRequestService.create(OkHttpSender.create(connectivity.getUrl(), okhttpClient))
builder.setRequestService(requestService)to Experimental.setServiceFactory(builder, endpoint -> HttpRequestService.create(OkHttpSender.create(endpoint, okhttpClient)));I'd say it isn't too bad usability wise. Explicitly having to go through a class named There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Got it, thanks for the example. I agree it's not too bad, I just have the following questions:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
because eventually we'd like it to be not experimental, got to start from somewhere
we could expose these in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is the confusing part for me, I think we both want the same, but from my point of view, hiding the API away will actually slow this process down.
Sounds good. Still, I'd suggest adding the factory method right away. If anything, having to provide a preconfigured object to do the network connectivity shouldn't be weird for OTel users, as that's essentially what we do with the |
||
| OpampClientBuilder builder, Function<URI, RequestService> serviceFactory) { | ||
| if (setServiceFactory != null) { | ||
| setServiceFactory.accept(builder, serviceFactory); | ||
| } | ||
| } | ||
|
|
||
| public static void internalSetServiceFactory( | ||
| BiConsumer<OpampClientBuilder, Function<URI, RequestService>> setServiceFactory) { | ||
| Experimental.setServiceFactory = setServiceFactory; | ||
| } | ||
|
|
||
| private Experimental() {} | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems a little unconventional in Java to use a function for this kind of thing. I'd prefer that we just stick with using a method...which I think can even be static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently we allow users replace this factory function, so they could customize things. Ideally eventually this will go away when we can provide users an option to customize the okhttp client without having to mess with the RequestService or HttpSender implementations.