Tracer configuration spec compliance

[NthPortal]

From https://opentelemetry.io/docs/specs/otel/trace/api/#get-a-tracer:

Tracers are identified by name, version, and schema_url fields. When more than one Tracer of the same name, version, and schema_url is created, it is unspecified whether or under which conditions the same or different Tracer instances are returned. It is a user error to create Tracers with different attributes but the same identity.

The term identical applied to Tracers describes instances where all identifying fields are equal. The term distinct applied to Tracers describes instances where at least one identifying field has a different value.

Implementations MUST NOT require users to repeatedly obtain a Tracer again with the same identity 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 Tracers.

Note: This could, for example, be implemented by storing any mutable configuration in the TracerProvider and having Tracer implementation objects have a reference to the TracerProvider from which they were obtained. If configuration must be stored per-tracer (such as disabling a certain tracer), the tracer could, for example, do a look-up with its identity in a map in the TracerProvider, or the TracerProvider could maintain a registry of all returned Tracers and actively update their configuration if it changes.

The effect of associating a Schema URL with a Tracer MUST be that the telemetry emitted using the Tracer will be associated with the Schema URL, provided that the emitted data format is capable of representing such association.

How do otel4s Tracer instances comply with the specification not to "require users to repeatedly obtain a Tracer again with the same identity to pick up configuration changes"? Does otel4s simply not support Tracer configuration changes at runtime, rendering it vacuously spec compliant?

Additionally, regarding the last paragraph, does otel4s simply rely on the backing Java sdk to handle Schema URL compliance?

[iRevive]

Since we wrap the Java SDK, we should be compliant.

The implementation uses a cache under the hood. When you try to create a new component (Tracer, in our case), an instance will be looked up based on the name, version, and schema URL.

Here is an example:
https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/common/src/main/java/io/opentelemetry/sdk/internal/ComponentRegistry.java

For our SDK implementation, we should take this into account indeed.