Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Clarify that Scope attributes are not part of its identity #2794

Closed
wants to merge 1 commit into from
Closed

Clarify that Scope attributes are not part of its identity #2794

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions specification/logs/api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -100,13 +100,13 @@ SHOULD be true by default.
associate with emitted telemetry.

Implementations MUST return different `Logger` instances when called repeatedly
with different values of parameters. Note that always returning a new `Logger`
with different values of (name,version,schema_url) parameters. Note that always returning a new `Logger`
instance is a valid implementation. The only exception to this rule is the no-op
`Logger`: implementations MAY return the same instance regardless of parameter
values.

Implementations MUST NOT require users to repeatedly obtain a Logger again with
the same name+version+schema_url+event_domain+include_trace_context+attributes
the same (name,version,schema_url) parameters
to pick up configuration changes. This can be achieved either by allowing to
work with an outdated configuration or by ensuring that new configuration
applies also to previously returned Loggers.
Expand All @@ -115,7 +115,7 @@ Note: This could, for example, be implemented by storing any mutable
configuration in the `LoggerProvider` and having `Logger` implementation objects
have a reference to the `LoggerProvider` from which they were obtained.
If configuration must be stored per-Logger (such as disabling a certain `Logger`),
the `Logger` could, for example, do a look-up with its name+version+schema_url+event_domain+include_trace_context+attributes
the `Logger` could, for example, do a look-up with its (name,version,schema_url)
in a map in the `LoggerProvider`, or the `LoggerProvider` could maintain a registry
of all returned `Logger`s and actively update their configuration if it changes.

Expand Down
8 changes: 4 additions & 4 deletions specification/metrics/api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -150,17 +150,17 @@ This API MUST accept the following parameters:
Meters are identified by all of these parameters.

Implementations MUST return different `Meter` instances when called repeatedly
with different values of parameters. Note that always returning a new `Meter` instance
with different values of (name,version,schema_url) parameters. Note that always returning a new `Meter` instance
is a valid implementation. The only exception to this rule is the no-op `Meter`:
implementations MAY return the same instance regardless of parameter values.

It is unspecified whether or under which conditions the same or different
`Meter` instances are returned from this function when the same
(name,version,schema_url,attributes) parameters are used.
(name,version,schema_url) parameters are used.

The term *identical* applied to Meters describes instances where all identifying fields
are equal. The term *distinct* applied to Meters describes instances where at
least one identifying field has a different value.
(name,version,schema_url) are equal. The term *distinct* applied to Meters describes instances where at
least one of identifying fields (name,version,schema_url) has a different value.

Implementations MUST NOT require users to repeatedly obtain a `Meter` with
the same identity to pick up configuration changes. This can be
Expand Down
4 changes: 2 additions & 2 deletions specification/trace/api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -132,12 +132,12 @@ This API MUST accept the following parameters:
to associate with emitted telemetry.

Implementations MUST return different `Tracer` instances when called repeatedly
with different values of parameters. Note that always returning a new `Tracer` instance
with different values of (name,version,schema_url) parameters. Note that always returning a new `Tracer` instance
is a valid implementation. The only exception to this rule is the no-op `Tracer`:
implementations MAY return the same instance regardless of parameter values.

Implementations MUST NOT require users to repeatedly obtain a `Tracer` again
with the same name+version+schema_url+attributes to pick up configuration changes.
with the same (name,version,schema_url) parameters to pick up configuration changes.
This can be achieved either by allowing to work with an outdated configuration or
by ensuring that new configuration applies also to previously returned `Tracer`s.

Expand Down