OpenTelemetry JDBC instrumentation shouldn't initialize OpenTelemetry at build time

[michalvavrik]

Is your feature request related to a problem? Please describe.

Quarkus is using OpenTelemetryDatasource in the Quarkus Agroal extension, which allows users to trace JDBC queries. As we create OpenTelemetry at runtime (in order to support OpenTelemetry SDK Autoconfigure), we can't have classes statically accessing OpenTelemetry via GlobalOpenTelemetry#get at build time, however that's exactly what JdbcSingletons does:

opentelemetry-java-instrumentation/instrumentation/jdbc/library/src/main/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcSingletons.java

Line 19 in d57405f

createStatementInstrumenter(GlobalOpenTelemetry.get());

As JdbcSingletons is only used by OpenTelemetryDriver we have to remove both in order to adapt opentelemetry-jdbc for native mode. This shouldn't be necessary as we shouldn't need knowledge of jdbc.internal package, for it is an API that is unstable and can change at any time.

Describe the solution you'd like

As the driver is singleton and initialized statically, we need lazy io.opentelemetry.instrumentation.jdbc.internal.JdbcSingletons#STATEMENT_INSTRUMENTER to be lazily initialized. Either we can use volatile or synchronized for the initialization needs to be thread safe.

Describe alternatives you've considered

I don't see other options.

Additional context

I'm happy to take care of this when I find a little time, the problem is not time sensitive.

[trask]

Resolved by #9625 (also see #12963)