-
Notifications
You must be signed in to change notification settings - Fork 894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify the location of tracing's Context interaction. #1187
Clarify the location of tracing's Context interaction. #1187
Conversation
Co-authored-by: Christian Neumüller <christian+github@neumueller.me>
Actually, we may need to also remove the mention of |
I am against removing "static". I mean I'm open to improving the wording to make it more language neutral, but a Tracer instance MUST NOT be required to interact with the current span. This often leads to misunderstandings, such as that each named tracer manages it's own active span, or complaints such as "why do I need to provide an instrumentation library name to access the current span" (#586). EDIT: I would be OK with allowing nonstatic methods on the TracerProvider. |
Co-authored-by: Nikita Salnikov-Tarnovski <gnikem@gmail.com>
@carlosalberto we can do a separate PR for the "static" if you feel strongly. |
Clarifies the location of the tracing interaction with
Context
, i.e. we want to say that this logic can exist anywhere in the API, as long as it exists in a single place.The mention of a
TracingContextUtils
class seemed like a too-specific suggestion, hence the removal (in Java we had this class, but ended up putting theContext
interaction as static/instanceSpan
directly).