Thanks Markus! The MP spec world is acutally pretty confusing, imho (also with a lot of breakage in betweeen).
To bring our current progress on the list: Markus and myself are still looking into OpenTelemetry 1.0 to fix the remaining TCK test. Looks like it requires a specific OpenTelemetry ClientRequest|ResponseFilter to be registered on the JAX-RS client. Gruß Richard Am Freitag, dem 22.11.2024 um 10:42 +0100 schrieb Markus Jung: > Hey Richard, > > > I did some digging now and it seems like the format for the span > names > comes from the opentelemetry (not to be confused with microprofile > telemetry) specification: > https://opentelemetry.io/docs/specs/semconv/http/http-spans/#name > This appears to have been changed some time ago > https://github.com/open-telemetry/opentelemetry-specification/issues/2998 > > and landed in opentelemetry 1.23.0, so anything >= 1.23.0 will fail > the > microprofile telemetry 1.0 TCK. > > Running the TCK against smallrye-opentelemetry 2.3.2 (which uses > opentelemetry 1.20.2): > > [INFO] Results: > [INFO] > [ERROR] Failures: > [ERROR] BaggageTest>Arquillian.run:138->baggage:81 » > ConditionTimeout > Assertion condition defined as a > org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpanE > xporter > expected [2] but found [1] within 10 seconds. > [INFO] > [ERROR] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0 > > > I pushed the correct version of smallrye-opentelemetry to your branch > :) > > > Thanks > > Markus > > > On 19.11.24 09:27, Richard Zowalla wrote: > > Hi all, > > > > On [1] you can find an experiment to replace OpenTracing 3 with > > OpenTelemetry 1.0 for MicroProfile 6+ > > > > The current status of the (super small TCK for it) is, that we have > > a few failures due to different expectations between span names in > > the test assumption (although the actual path looks fine). > > > > [ERROR] BaggageTest>Arquillian.run:138->baggage:81 » > > ConditionTimeout Assertion condition defined as a > > org.eclipse.microprofile.telemetry.tracing.tck.exporter.InMemorySpa > > nExporter expected [2] but found [1] within 10 seconds. > > [ERROR] RestSpanTest>Arquillian.run:138->span:107 expected > > [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span] but found [GET > > /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span] > > [ERROR] RestSpanTest>Arquillian.run:138->spanName:128 expected > > [/4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] but found [GET > > /4ceb08bf-e548-4e5d-aa26-e64d2f5b4e89/span/{name}] > > [ERROR] RestSpanTest>Arquillian.run:138- > > >spanNameWithoutQueryString:140 expected [/4ceb08bf-e548-4e5d-aa26- > > e64d2f5b4e89/span/{name}] but found [GET /4ceb08bf-e548-4e5d-aa26- > > e64d2f5b4e89/span/{name}] > > > > I didn’t find any clarification in the spec [2] what the span name > > should be (http route vs http method + http route). Does anyone has > > a glue for it? > > > > Regardless of that, it seems, that the MP people have rewritten the > > test suite for OpenTelemetry 2.0 (MP7) completely and this > > assertions aren’t present anymore (maybe because they were just > > vendor specific?!). > > > > So I don’t know, how we want to proceed here. > > > > On the one hand, it might be good to drop OpenTracing in favor of > > the OpenTelemetry 1.0 integration although we do not pass the TCK > > for it but would be a step towards MP6+ (and to upgrade from 1.0 to > > 2.0 might be easier). > > On the other hand, the OpenTracing implementation brings in a lot > > of crappy dependencies (imho) with some of them being in alpha > > state bloating our distribution. > > > > Questions: > > > > - (1) Does anyone has a glue regarding the span naming? Maybe > > someone wants to do some digging on this too? > > - (2) How do we want to proceed? > > > > Gruß > > Richard > > > > [1] https://github.com/apache/tomee/tree/TOMEE-4343 > > [2] > > https://download.eclipse.org/microprofile/microprofile-telemetry-1.0/tracing/microprofile-telemetry-tracing-spec-1.0.html > > > >
