Description
OpenTracing 0.32.0 Added support to access the Trace and Span IDs.
https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md
These IDs are needed in order to correlate logs to traces ( using MDC ) and to return correlation IDs to an API consumer.
Before this specification was updated, obtaining the IDs required breaking encapsulation and hacking in access to the IDs. Quarkus currently utilizes opentracing 0.31.0.
Jaeger-java-client Added support for OpenTracing 0.32.0 originally in version 0.35.0, and they are currently at 1.0.0 release version ( with support for opentracing 0.33.0 )
https://github.com/jaegertracing/jaeger-client-java/blob/master/CHANGELOG.md
@pavolloffay @objectiser could we upgrade our Jaeger dependencies? Or is it problematic?
Jaeger client in quarkus have to stay on 0.34.0 which implements OpenTracing 0.31.0 because MicroProfile-OpenTracing requires that API and unfortunately 0.32.0 contains breaking changes.
OpenTracing API in MicroProfile will be updated there is an outgoing discussion on this topic https://groups.google.com/forum/#!topic/microprofile/unYFj9EpTgM
Thats unfortunate. In the meantime, does quarkus have an avenue to retrieve the SpanId in a manner that is "Safer" than this or that wouldnt require casting down to the implementation underlying quarkus?
String spanId;
Span s = tracer.activeSpan();
SpanContext ctx = s == null ? null : s.context();
if (ctx != null && ctx instanceof JaegerSpanContext) {
//TODO: Fix this downcasting once Quarkus upgrades to Jaeger 0.35+
spanId = Long.toHexString(((JaegerSpanContext)ctx).getSpanId());
}
@pavolloffay I posted this question on that thread:
Hi Pavol,
Can you quantify the breaking the changes? Is the issue that the implementors of of the MP spec will have to add support for some new capabilities?
Or is it that consumers of the spec will be broken by API removal or API modifications ?
Thanks!
Have a look at OpenTracing changelog https://github.com/opentracing/opentracing-java/blob/master/CHANGELOG.md or run git compare against 0.31.0 and 0.32.0 and again 0.33.0.
Or is it that consumers of the spec will be broken by API removal or API modifications ?
Yes there are breaking API changes, which requires to modify/rewrite code if they use OpenTracing API explicitly (no auto-instrumentation)