Summary
The Strimzi image bundles OpenTelemetry 1.34.1 via kafka-thirdparty-libs, while the AutoMQ Kafka tarball ships OpenTelemetry 1.40.0. Both sets of jars end up in the flat /opt/kafka/libs/ directory, causing version conflicts at runtime.
Related Issues
Root Cause
The Strimzi image build (AutoMQ/strimzi-kafka-operator) copies all jars into /opt/kafka/libs/:
| Source |
OTel Version |
Key Jars |
| AutoMQ tarball |
1.40.0 |
exporter-otlp, sdk, sender-okhttp, sender-jdk |
Strimzi thirdparty-libs (pom.xml) |
1.34.1 |
exporter-otlp, sdk, sender-jdk (1.34.1-alpha), sender-grpc-managed-channel |
When two versions of the same OTel artifact coexist on the classpath, the JVM may load a class from one version and an interface from another. Specifically:
HttpExporterBuilder (1.40.0) calls HttpSenderProvider.createSender(...) with the 1.40.0 method signature
ServiceLoader may resolve OkHttpHttpSenderProvider from the 1.34.1 jar (or vice versa)
- The method signature changed between 1.34.1 and 1.40.0 →
AbstractMethodError
The find-classpath-collision.sh script in Strimzi catches class-level collisions but not same-artifact version mismatches, so this slips through the build.
Why previous fixes were incomplete
The real fix needs to happen in AutoMQ/strimzi-kafka-operator's kafka-thirdparty-libs/pom.xml.
Proposed Fixes (in strimzi-kafka-operator)
Option A: Upgrade OTel version to match AutoMQ (minimal change)
Align kafka-thirdparty-libs/3.9.x/pom.xml and 4.0.x/pom.xml to 1.40.0:
<opentelemetry.version>1.40.0</opentelemetry.version>
<opentelemetry-alpha.version>1.40.0-alpha</opentelemetry-alpha.version>
- Pros: minimal diff, both sides use the same version, no behavioral change.
- Cons: still ships duplicate jars (one from AutoMQ tarball, one from thirdparty-libs). Needs to be re-aligned whenever AutoMQ upgrades OTel.
Option B: Remove duplicate OTel dependencies from thirdparty-libs (thorough)
Since the AutoMQ tarball already ships a complete set of OTel jars (sdk, exporters, senders), the thirdparty-libs pom.xml should stop declaring them. Only keep what AutoMQ does not provide (e.g., opentelemetry-kafka-clients-2.6 for Strimzi tracing, opentelemetry-sdk-extension-autoconfigure).
<!-- Remove these from pom.xml (already in AutoMQ tarball): -->
<!-- opentelemetry-exporter-otlp -->
<!-- opentelemetry-exporter-sender-jdk -->
<!-- opentelemetry-exporter-sender-grpc-managed-channel -->
<!-- grpc-netty-shaded -->
<!-- Keep these (Strimzi-specific, not in AutoMQ tarball): -->
<!-- opentelemetry-sdk-extension-autoconfigure -->
<!-- opentelemetry-kafka-clients-2.6 -->
- Pros: eliminates duplication at the source, no version drift risk.
- Cons: larger change, requires verifying exactly which OTel jars the AutoMQ tarball provides. Strimzi's tracing agent dependencies (
autoconfigure, kafka-clients-2.6) may also need version alignment.
Environment
- AutoMQ OTel SDK version: 1.40.0 (
gradle/dependencies.gradle)
- Strimzi thirdparty-libs OTel version: 1.34.1 (
kafka-thirdparty-libs/3.9.x/pom.xml and 4.0.x/pom.xml)
Summary
The Strimzi image bundles OpenTelemetry 1.34.1 via
kafka-thirdparty-libs, while the AutoMQ Kafka tarball ships OpenTelemetry 1.40.0. Both sets of jars end up in the flat/opt/kafka/libs/directory, causing version conflicts at runtime.Related Issues
AbstractMethodErrorinOkHttpHttpSenderProviderwhen OTLP HTTP exporter is enabledsender-okhttp, addedsender-jdkin AutoMQGrpcSenderProviderwas removed along withsender-okhttpsender-okhttpin AutoMQ (correct for AutoMQ standalone, but doesn't address the Strimzi conflict)Root Cause
The Strimzi image build (
AutoMQ/strimzi-kafka-operator) copies all jars into/opt/kafka/libs/:pom.xml)When two versions of the same OTel artifact coexist on the classpath, the JVM may load a class from one version and an interface from another. Specifically:
HttpExporterBuilder(1.40.0) callsHttpSenderProvider.createSender(...)with the 1.40.0 method signatureServiceLoadermay resolveOkHttpHttpSenderProviderfrom the 1.34.1 jar (or vice versa)AbstractMethodErrorThe
find-classpath-collision.shscript in Strimzi catches class-level collisions but not same-artifact version mismatches, so this slips through the build.Why previous fixes were incomplete
sender-okhttpand addedsender-jdkin AutoMQ to avoid theAbstractMethodError. This worked forprotocol=httpbut brokeprotocol=grpcbecauseGrpcSenderProvideris only provided bysender-okhttp.sender-okhttpin AutoMQ, which is correct for standalone AutoMQ. But in the Strimzi environment, the version mismatch between AutoMQ's 1.40.0 jars and Strimzi's 1.34.1 jars remains the root cause.The real fix needs to happen in
AutoMQ/strimzi-kafka-operator'skafka-thirdparty-libs/pom.xml.Proposed Fixes (in strimzi-kafka-operator)
Option A: Upgrade OTel version to match AutoMQ (minimal change)
Align
kafka-thirdparty-libs/3.9.x/pom.xmland4.0.x/pom.xmlto 1.40.0:Option B: Remove duplicate OTel dependencies from thirdparty-libs (thorough)
Since the AutoMQ tarball already ships a complete set of OTel jars (sdk, exporters, senders), the thirdparty-libs
pom.xmlshould stop declaring them. Only keep what AutoMQ does not provide (e.g.,opentelemetry-kafka-clients-2.6for Strimzi tracing,opentelemetry-sdk-extension-autoconfigure).autoconfigure,kafka-clients-2.6) may also need version alignment.Environment
gradle/dependencies.gradle)kafka-thirdparty-libs/3.9.x/pom.xmland4.0.x/pom.xml)