Maksym Ochenashko

@NthPortal I don't think we should entirely give up on this design. I agree that the lifecycle should be encapsulated and fully managed by the internals. If we find the...

The MBean version (JVM only) is available here - https://github.com/typelevel/otel4s-experimental?tab=readme-ov-file#1-iometrics---cats-effect-runtime-metrics.

There is a basic implementation available https://github.com/typelevel/cats-effect/pull/3317. On the otel4s side, we should use observable (async) metrics #158.

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),...

This behavior was supported in the very first draft. Turned out it does not work the way we want with `Local[F, Vault]`. There are a few discussions regarding this topic:...

We will eliminate `wrapResource` in the upcoming release. A follow-up to #273. To summarize: it's not possible to trace the resource now (e.g. different stages: acquire, use, release; and stay...

`Local` semantics doesn't go along with the `Resource`. > [!Warning] > The code below provides a leaky abstraction, please don't use it However, there is a workaround to make it...

> i.e. you can't set anything `SpanRef` has a `Span.Backend` inheritance constraint: https://github.com/typelevel/otel4s/blob/827f5f0910caf9051cb19289dea6bae29dcab2bf/sdk/trace/src/main/scala/org/typelevel/otel4s/sdk/trace/SpanRef.scala#L37 You can access all mutating operations: `updateName`, `setStatus`, etc.

[ReadableSpan](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/trace/src/main/java/io/opentelemetry/sdk/trace/ReadableSpan.java) defines methods that we currently have in `SpanRef`: `name`, `toSpanData`, etc. [ReadWriteSpan](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/trace/src/main/java/io/opentelemetry/sdk/trace/ReadWriteSpan.java) extends `ReadableSpan` and `Span`.

Hey @bio-aeon, you can work on it. Thanks in advance!