Move useSpan() out of Tracer
See original GitHub issueCurrently the Specification expects that the current Span handling happens in a single place, either module level functions or in a class, and whereas set_span_in_context()
and get_current_span()
live in the trace
module, useSpan()
exists in the Tracer
.
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (11 by maintainers)
Top Results From Across the Web
opentracing/public - Gitter
For moving a span across threads, use span.activate() and span.deactivate() . The currently active span can be accessed via tracer.activeSpan() .
Read more >v1.6.3 — ddtrace documentation - Read the Docs
Use Span.set_tag_str() instead of Span.set_tag() when the tag value is a text type ... since the tracer now supports asynchronous frameworks out of...
Read more >Java Custom Instrumentation - Datadog Docs
Implement the OpenTracing standard with the Datadog Java APM tracer. ... set the error tag on the span and use Span.log() to set...
Read more >Tracing Best Practices | Tanzu Observability Documentation
Java example: Instantiate a singleton WavefrontTracer , pass it to each class, and use it in ... public String tier2a() { String response...
Read more >Manual Instrumentation | OpenTelemetry
Getting a Tracer To create spans, you'll need to acquire or initialize a tracer first. ... To get the current span, you'll need...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
opentelemetry.trace.use_span()
sounds fine as it’s a convenience method as @owais pointed out, so I suggest going that path 😉The spec actually clarifies this at the very end in the following section. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status
So looks like this check is unnecessary and should actually be removed. I’ll update the PR accordingly.