Details
-
Task
-
Resolution: Done
-
Undefined
-
None
-
None
Description
Hi,
we were working on the OpenTracing removal with the hope that okhttp was going away somehow together with the Kotlin dependencies for which we still have "exceptions" to deliver the non-productized ones to customers.
I mistakenly said that AMQ Streams 2.5.0 was going to be the last version having the need for the Kotlin "exceptions". Unfortunately, it's not actually true 
While removing OpenTracing from the operator and the bridge, it turned out that the OpenTelemetry OTLP exporter still brings okhttp + kotlin as direct dependencies (without removing Jaeger and OpenTracing dependencies, maven showed me okhttp + kotlin as dependencies of them only, actually hiding they were used in the OTLP exporter as well).
From an OpenTelemetry perspective, I noticed that they recently added a new exporter "sender" based on the JDK HTTP client alongside the current okhttp based one. It's really new (PR was merged in July) and in an early stage but you can swap to use it. More details in this discussion [1] I had with the contributor of this feature.
On the other side, we were wondering how Quarkus was dealing with it, in terms of usage of OpenTelemetry and the okhttp + kotlin stuff it brings.
From discussions I had in the past with Quarlus people, it seems that Quarkus doesn't actually use the "official" OpenTelemetry OTLP exporter but an "homemade" one not using okhttp.
Also, in the coming Quarkus 3.3.0 they seemed to come back to using the "official" OpenTelemetry OTLP exporter but somehow replacing the okhttp backend with a Vert.x one. See more details on this PR [2].
Here it comes to a decision we should make for the next AMQ Streams 2.6.0 release ...
Sticking with the Kotlin "exceptions" because we are still relying on the OpenTelemetry OTLP exporter using okhttp while waiting to see if the JDK HTTP based sender becomes "mature" or just swapping to it and test in order to get rid of the Kotlin "exceptions" immediately.
I would try to avoid any kind of investigation in the direction of using somehow the Quarkus-ish one, even because we are moving away from Vert.x so it would not make any sense. Also, even tightening Strimzi to some Quarkus related stuff is not a great choice imho.
[1] https://github.com/open-telemetry/opentelemetry-java/discussions/5703
[2] https://github.com/quarkusio/quarkus/pull/34647
