Opentelemetry-java: Extraction/Injection of `Span` from/into the carrier should not be dependent on `Context`

[arjun-1]

Right now, both extract and inject on HttpTextFormat require a context Context as parameter. The actual extraction is not dependent on the Context, and the context is merely used as a 'medium' to store the extracted span in.
Indeed, this actual extraction happens in extractImpl (note that this is not exposed in the SDK).

This is problematic for library developers using the Java Opentelemetry API. Some libraries wrapping the SDK would not like to use the ThreadLocalStorage as used in Context.current(), but want to use their own variant.

For example zio-telemetry uses FiberRef instead. Note that in OpenTracing, it is possible to do extraction and injection of the Span independent of the Context.

Ideally this would also be the case for the Java OpenTelemetry SDK

[carlosalberto]

@arjun-1 We will be exploring in the next weeks our options there, to decide how to handle the context storage.

The idea has been, so far, to make context propagation a public member, while ideally keeping it hidden for most of the users.

(Related to #575 )

[arjun-1]

Good to hear you're already on the problem :slightly_smiling_face: .

[Oberon00]

@arjun-1 Context can be used without ThreadLocalStorage or using Context.current() just fine, can't it? I think you assume a closer relationship between where the context of Context.current() is stored and Context itself than it actually is.

[arjun-1]

@Oberon00 I hope I understand your comment correctly

Looking at HttpTextFormat.extract:

<C> Context extract(Context context, C carrier, Getter<C> getter);

This method is of interest to me, only to extract the span Span from carrier C. Note that I'm not really interested in the Context that is returned by this method, but only in the span residing in it (under key CONTEXT_SPAN_KEY).

In the ideal world I would be able to use something similar to

private static <C> SpanContext extractImpl(C carrier, Getter<C> getter)

and be able to retrieve a Span, computed only from parameters carrier C and getter Getter<C>

Indeed you are right that I can use Context without ThreadLocalStorage. For example through Context.Root I suppose?

I could call extract using Context.Root and use TracingContextUtils.getSpan to get the span I'm after:

TracingContextUtils.getSpan(httpTextFormat.extract(Context.ROOT, carrier, getter))

I had some fears about this, given that EMPTY_ENTRIES and ROOT are static and mutable which could potentially lead to race conditions in a concurrent environment. It's just a fear I head, so feel free to correct me if I'm wrong.

[Oberon00]

If ROOT is mutable and static, that' a problem. The context is supposed to be immutable, I think. @carlosalberto ?

[carlosalberto]

That's correct - io.grpc.Context is immutable, and so is ROOT.

[arjun-1]

I stand corrected :slightly_smiling_face: . Thank a lot, this is helpful information

[Oberon00]

Is this issue resolved then?

[arjun-1]

From my side: yes. There is nothing particular which inhibits my usage of java open-telemetry