CONTEXT_*_SPAN_KEY need to be moved to bootstrap and accessed through bridging?

[anuraaga]

If I'm not mistaken, these keys will not function correctly when using both the agent and library instrumentation together since the key will be shaded in one and not compatible. I think these need to be moved to a location in the bootstrap classloader, with methods to get / set these. The opentelemetry-api instrumentation will need to also instrument these methods to perform bridging for these operations in the app classloader since they accept a Span.

[trask]

I think these need to be moved to a location in the bootstrap classloader, with methods to get / set these.

these are in instrumentation-api which is (shaded) in the bootstrap classloader already

The opentelemetry-api instrumentation will need to also instrument these methods to perform bridging for these operations in the app classloader since they accept a Span.

👍

[trask]

I think this is needed for a common use case for end users too: adding attributes to the SERVER span, but finding yourself under a spring controller INTERNAL span so you can't use Span.current().

Maybe ServerSpan.current() or something similarly friendly?

[mateuszrzeszutek]

As an additional improvement, we could also set the library Config so that it contains exactly the same configuration as the javaagent: config file & SPI included.