Closed hzpz closed 3 weeks ago
I'm going to move this over to the instrumentation repository, since it involves the functioning of the spring-boot-starter and not the SDK or API themselves.
@zeitlinger could you take a look
@jkwatson it's not really about spring IIUC
this is part of the dependency tree
opentelemetry-api-incubator
or bad stuff can happen (like this one) | +--- io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:1.39.0 -> 1.40.0
| | \--- io.opentelemetry:opentelemetry-sdk:1.40.0
| | +--- io.opentelemetry:opentelemetry-api:1.40.0 (*)
| | +--- io.opentelemetry:opentelemetry-sdk-common:1.40.0 (*)
| | +--- io.opentelemetry:opentelemetry-sdk-trace:1.40.0
| | | +--- io.opentelemetry:opentelemetry-api-incubator:1.40.0-alpha -> 1.39.0-alpha
@jkwatson it's not really about spring IIUC
this is part of the dependency tree
- SDK needs to have the same version of
opentelemetry-api-incubator
or bad stuff can happen (like this one)- if the user doesn't want to use alpha artifacts, why should they be forced to use the alpha bom?
| +--- io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:1.39.0 -> 1.40.0 | | \--- io.opentelemetry:opentelemetry-sdk:1.40.0 | | +--- io.opentelemetry:opentelemetry-api:1.40.0 (*) | | +--- io.opentelemetry:opentelemetry-sdk-common:1.40.0 (*) | | +--- io.opentelemetry:opentelemetry-sdk-trace:1.40.0 | | | +--- io.opentelemetry:opentelemetry-api-incubator:1.40.0-alpha -> 1.39.0-alpha
What is causing the downgrade of the incubator module?
Try using opentelemetry-instrumentation-bom-alpha
2.6.0-alpha
.
The issue is that opentelemetry spring boot starter 2.5.0
is compatible with opentelemetry sdk 1.39.0
but here 1.40.0
is used. It is io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom-alpha:2.5.0-alpha
that sets opentelemetry-api-incubator
version to 1.39.0-alpha
. The way I see it we could solve it by changing the documentation to also use opentelemetry-bom-alpha
or say that users who who use instrumentation with a different sdk version than what the instrumentation was tested with should figure this and other potential issues out on their own.
The SDK is stable and hence should be backwards compatible. So it SDK depends on the incubator API, then the incubator API should be in the stable BOM IMO.
@jkwatson @jack-berg since opentelemetry-api-incubator
is a required dependency of stable sdk components wdyt of also setting its version in opentelemetry-bom
?
Yeah this is weird.
opentelemetry-sdk
is part of opentelemetry-bom
and has a transitive dependency on opentelemetry-api-incubator
which is not part of opentelemetry-bom
. opentelemetry-api-incubator
is part of opentelemetry-bom-alpha
, which is included in opentelemetry-instrumentation-bom-alpha
.
The user has dependencies on opentelemetry-bom
and opentelemetry-instrumentation-bom-alpha
which are conflicting with each other: opentelemetry-instrumentation-bom-alpha
version is 2.5.0
, which targets opentelemetry-bom
version 1.39.0
. But the user also places a direct dependency on opentelemetry-bom
version 1.40.0
.
Ironically, the fix is to just eliminate the opentelemetry-bom
dependency, since that is included automatically already with opentelemetry-instrumentation-bom-alpha
.
But it might also be time to consider whether we even want an alpha bom anymore. As of now, there are 4 dependencies in it, two of which will never be stable by design: opentelemetry-opencensus-shim
, opentelemetry-api-incubator
, opentelemetry-exporter-prometheus
, opentelemetry-sdk-extension-incubator
.
Maybe its enough to say that we have a single bom, and that you should consult the artifacts table for the stability status of dependencies.
Or we can make it clear to users that a dependency on the instrumentation bom (opentelemetry-instrumentation-bom-alpha
) supersedes a dependency on any core repo boms and you should only use one or the other based on your needs.
I am having the same issue- except for a different class - io/opentelemetry/sdk/autoconfigure/spi/internal/AutoConfigureListener. I have tried to add the below dependency but that didn't resolve the issue
implementation 'io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:1.40.0'
@srigollamudi create a new issue, include stack trace. A minimal application that reproduces the issue would be nice.
Will do. thx!
I think this got resolved with a documentation change.
Describe the bug Setting up the OpenTelemetry Spring Boot Starter as described in the documentation using the recently released version 1.40.0 will prevent the Spring Boot context from loading due to a missing class.
Steps to reproduce Create a Spring Boot project with start.spring.io, add the OpenTelemetry dependencies as described in the documentation. For a minimal example see: https://github.com/hzpz/opentelemetry-needs-incubator
What did you expect to see? The Spring Boot context should load.
What did you see instead? The Spring Boot context failed to load.
What version and what artifacts are you using?
io.opentelemetry.instrumentation:opentelemetry-instrumentation-bom-alpha:2.5.0-alpha
io.opentelemetry:opentelemetry-bom:1.40.0
io.opentelemetry.instrumentation:opentelemetry-spring-boot-starter
Environment Compiler: Temurin 21.0.2 OS: macOS 14.5
Additional context The Spring Boot context loads if I either
io.opentelemetry:opentelemetry-api-incubator:1.40.0-alpha
io.opentelemetry:opentelemetry-bom:1.40.0
toio.opentelemetry:opentelemetry-bom-alpha:1.40.0-alpha
Stacktrace