Mateusz Rzeszutek

Sure! I should be able to do this this week.

I think that the AWS Xray propagator should probably stay in the SDK; and that we should change the spec to reflect that. I view it as a component that...

> We could take it one step further and move even the spec'd shims to `opentelemetry-java-instrumentation` (opentracing and opencensus). One possible problem with the OpenCensus bridge is that it's impossible...

> Due to the presence of a growing number of library instrumentation artifacts, I've been viewing the instrumentation repo as a general home for instrumentation, which also publishes an agent...

> Are you saying we should escape the json-array so that it can be coerced into a String? Hmm, possibly? I think that's what we do in Jaeger (well, it's...

> I think this was implemented by @mateuszrzeszutek now > > https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/micrometer/micrometer-1.5/library This PR seems to implement the reverse bridge: OTel -> Micrometer. Anyway -- is this still valid/needed?

There are advantages to calling OTel API in micrometer bridge instrumentation: * Micrometer instruments like `Timer` and `DistributionSummary` can be translated to native OTel histograms; micrometer does not have a...

> > Micrometer instruments like Timer and DistributionSummary can be translated to native OTel histograms; micrometer does not have a "histogram" meter by itself, it basically exports each bucket as...

> the option to unregister callbacks is enough, coupled with memory options for exporters? Or are you looking for something like Prometheus' `Delete()`? I believe that should be enough. Removing...

I have a couple of questions/observations regarding the HTTP headers use case: 1. If we allow adding nested structures/maps to `Attributes`, what type should the attribute key represent? Also `Attributes`?...