ClassNotFoundException for DbClientMetrics

[wimdeblauwe-volvo]

Describe the bug

I want to add opentelemetry-spring-boot-starter to my Spring Boot 3.4.4 application. I have added the dependency management section:

<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>io.opentelemetry.instrumentation</groupId>
				<artifactId>opentelemetry-instrumentation-bom</artifactId>
				<version>2.14.0</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

And the dependency:

		<dependency>
			<groupId>io.opentelemetry.instrumentation</groupId>
			<artifactId>opentelemetry-spring-boot-starter</artifactId>
		</dependency>

When I try to start my application, I get a ClassNotFoundException.

Relevant part of the stacktrace:

Caused by: java.lang.NoClassDefFoundError: io/opentelemetry/instrumentation/api/incubator/semconv/db/DbClientMetrics
	at io.opentelemetry.instrumentation.jdbc.internal.JdbcInstrumenterFactory.createStatementInstrumenter(JdbcInstrumenterFactory.java:56)
	at io.opentelemetry.instrumentation.jdbc.datasource.JdbcTelemetryBuilder.build(JdbcTelemetryBuilder.java:50)
	at io.opentelemetry.instrumentation.spring.autoconfigure.internal.instrumentation.jdbc.DataSourcePostProcessor.postProcessAfterInitialization(DataSourcePostProcessor.java:58)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:439)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1815)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:601)
	... 34 common frames omitted
Caused by: java.lang.ClassNotFoundException: io.opentelemetry.instrumentation.api.incubator.semconv.db.DbClientMetrics
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 40 common frames omitted

As a workaround, I can add this dependency:

		<dependency>
			<groupId>io.opentelemetry.instrumentation</groupId>
			<artifactId>opentelemetry-instrumentation-api-incubator</artifactId>
			<version>2.14.0-alpha</version>
		</dependency>

After that, things work.

Steps to reproduce

See description.

Expected behavior

I would expect the extra dependency to not be needed.

Actual behavior

The extra dependency is needed

Javaagent or library instrumentation version

2.14.0

Environment

JDK: 21
OS: macOS

Additional context

No response

[laurit]

Instead of opentelemetry-instrumentation-bom try opentelemetry-instrumentation-bom-alpha https://central.sonatype.com/artifact/io.opentelemetry.instrumentation/opentelemetry-instrumentation-bom-alpha/2.14.0-alpha/versions My guess is that there is something in your project that forces using an older incompatible version of opentelemetry-instrumentation-api-incubator. You probably can figure out what is going on by examining the output of ./mvnw dependency:tree @zeitlinger @jeanbisutti perhaps the documentation should use the instrumentation alpha bom?

[wimdeblauwe-volvo]

Thank you for that tip, that indeed fixes the issue.

When I compare the Maven dependency tree using the alpa and non-alpha boms, then I see that io.micrometer:micrometer-tracing-bridge-otel:jar:1.4.4:compile in my dependencies has a dependency on io.opentelemetry.instrumentation:opentelemetry-instrumentation-api-incubator:jar:2.9.0-alpha:compile.

I am combining the opentelemtry Spring Boot starter with these 3 dependencies:

        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-registry-otlp</artifactId>
        </dependency>
        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-tracing-bridge-otel</artifactId>
        </dependency>
        <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-exporter-otlp</artifactId>
        </dependency>

The reason is that I don't get traces otherwise for JMS messages sent over IBM MQ. With those dependencies I can see them in Tempo (I am using grafana/otel-lgtm in docker for testing).

[zeitlinger]

You probably can figure out what is going on by examining the output of ./mvnw dependency:tree @zeitlinger @jeanbisutti perhaps the documentation should use the instrumentation alpha bom?

We could - but using alpha could also confuse users - because the starter is stable and does not (or should not) rely on alpha artifacts.

@trask do you remember if we discussed this question during the stabilization of the starter?

[laurit]

because the starter is stable and does not (or should not) rely on alpha artifacts.

starter depends on instrumentations, none of which are stable

[zeitlinger]

because the starter is stable and does not (or should not) rely on alpha artifacts.

starter depends on instrumentations, none of which are stable

how can this ever have worked?

[jeanbisutti]

@zeitlinger @laurit @trask From what I remember of the discussions on the starter stability, "stable" means that the API is stable. The starter is stable but the implementation of the stater depends on OTel dependencies having unstable API. An alternative to open-telemetry/opentelemetry.io#6665 would be to add a side note on the doc suggesting to use the alpha bom in case of java.lang.ClassNotFoundException: io.opentelemetry.instrumentation.api.incubator.semconv..

[zeitlinger]

@zeitlinger @laurit @trask From what I remember of the discussions on the starter stability, "stable" means that the API is stable. The starter is stable but the implementation of the stater depends on OTel dependencies having unstable API. An alternative to open-telemetry/opentelemetry.io#6665 would be to add a side note on the doc suggesting to use the alpha bom in case of java.lang.ClassNotFoundException: io.opentelemetry.instrumentation.api.incubator.semconv..

that's too complicated I think

[trask]

@trask do you remember if we discussed this question during the stabilization of the starter?

we didn't consider that another library's bom might reference our incubating modules 😢

@wimdeblauwe-volvo the opentelemetry spring boot starter and micrometer-tracing-bridge-otel are not designed to work with each other, we'd really recommend choosing one or the other

[wimdeblauwe-volvo]

What about those other 2 dependencies? Can I use those with the starter?

[wimdeblauwe-volvo]

@trask Can you elaborate what the problem is with combining the 2? With both, I get this nice traces:

But if I remove micrometer-tracing-bridge-otel, the traces are not combined into a single flow like I am showing here. They all seem to be separate. How can I get this back if I remove that dependency?

[trask]

Can you elaborate what the problem is with combining the 2?

It's an untested scenario and you probably won't get support for this combination from either the Micrometer Tracing side or the OpenTelemetry side. If it's working for you though that's great.

[laurit]

closing as the original issue seems to be resolved