Support creating an UpstreamGrpcExporter without setChannel

[scjody]

Is your feature request related to a problem? Please describe. We need to use UpstreamGrpcExporter in order to use grpc-java because OkHttp 4 conflicts with another library we use that requires OkHttp 3. Currently this requires using the deprecated setChannel method in order to trigger this code path in GrpcExporterBuilder.

Describe the solution you'd like We would be happy to use setEndpoint, but we need another way to cause UpstreamGrpcExporterFactory to be used.

Describe alternatives you've considered The only other alternative I can see is for us to use UpstreamGrpcExporter or UpstreamGrpcExporterFactory directly, but both are marked "internal" and "not for public use": UpstreamGrpcExporter, UpstreamGrpcExporterFactory (in GrpcExporterBuilder).

[jack-berg]

Are you running into issues using OkHttp4 with a library that has a dependency on OkHttp3? OkHttp4 claims to be binary and source compatible with OkHttp3.

[scjody]

Yes, we're seeing those issues. We're using dd-trace-ot while transitioning from Datadog's OpenTracing to upstream OpenTelemetry. When we add a dependency on opentelemetry-exporter-otlp-common, our build system pulls in OkHttp4 and we get an exception on startup:

[info] java.lang.NoSuchFieldError: Companion
[info] 	at okhttp3.internal.Util.<clinit>(Util.kt:70)
[info] 	at okhttp3.HttpUrl$Builder.parse$okhttp(HttpUrl.kt:1239)
[info] 	at okhttp3.HttpUrl$Companion.get(HttpUrl.kt:1634)
[info] 	at okhttp3.HttpUrl$Companion.parse(HttpUrl.kt:1643)
[info] 	at okhttp3.HttpUrl.parse(HttpUrl.kt)
[info] 	at datadog.communication.ddagent.SharedCommunicationObjects.createRemaining(SharedCommunicationObjects.java:22)
[info] 	at datadog.trace.core.CoreTracer.<init>(CoreTracer.java:491)
[info] 	at datadog.trace.core.CoreTracer.<init>(CoreTracer.java:86)
[info] 	at datadog.trace.core.CoreTracer$CoreTracerBuilder.build(CoreTracer.java:380)
[info] 	at datadog.opentracing.DDTracer.<init>(DDTracer.java:400)
[info] 	at datadog.opentracing.DDTracer.<init>(DDTracer.java:39)
[info] 	at datadog.opentracing.DDTracer$DDTracerBuilder.build(DDTracer.java:166)
[...traces from our app itself removed...]

I'm aware that OkHttp claims compatibility but this doesn't seem to be the case.

We also tried excluding OpenTelemetry's OkHttp dependency (forcing it to use OkHttp3 3.12.12 pulled in by dd-trace-ot) and that fails as well:

[error] Exception in thread "okhttp-dispatch-1" java.lang.NoSuchMethodError: okhttp3.Response.trailers()Lokhttp3/Headers;
[error] 	at io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter.grpcStatus(OkHttpGrpcExporter.java:183)
[error] 	at io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter.access$300(OkHttpGrpcExporter.java:54)
[error] 	at io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter$1.onResponse(OkHttpGrpcExporter.java:132)
[error] 	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
[error] 	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
[error] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[error] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[error] 	at java.lang.Thread.run(Thread.java:748)

[laurit]

@scjody If you need a solution for this right now then your best option is to shade otel dependencies and relocate okhttp3 and okio packages so that they wouldn't conflict with the okhttp you already have. If it is easier you could also shade the datadog libraries with the okhttp they use.

[jack-berg]

I believe this was resolved in #6110.