Jack Berg

Yeah the collector scrapers behavior is weird at the moment. At the current collector contrib head (with unpublished changes that parse target info), if I scrape the prometheus endpoint exposed...

After chatting with @anuraaga, we think the spec needs to clarify its language. Opened this [spec issue](https://github.com/open-telemetry/opentelemetry-specification/issues/2640) to track.

See this [comment](https://github.com/open-telemetry/opentelemetry-java/pull/4569#issuecomment-1190500176) for an update on this issue.

An additional problem is that log processors only have access to [LogData](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/logs/src/main/java/io/opentelemetry/sdk/logs/data/LogData.java) - there are no methods to mutate. This is problematic because it means that if trying to implement...

I made this [example](https://github.com/jack-berg/opentelemetry-java/blob/context-log-processor/sdk-extensions/autoconfigure/src/testFullConfig/java/io/opentelemetry/sdk/autoconfigure/ContextLogProcessorTest.java#L37-L76) to get a better feel for what it would take to do context extraction via an autoconfigure extension point. Yuck.

> IMO baggage isn't an ideal example since it's supposed to be handled by OTel itself. Could you expand on this? I think you're saying there should be built in...

Opened spec issue [#2674](https://github.com/open-telemetry/opentelemetry-specification/issues/2647) to request allowing this.

@anuraaga I don't think we've seen this type of issue in a while. Is it still relevant?

Found #575 that explains the desire to keep `opentelemetry-context` separate. I think the explanation of having a standalone context API to not be tied to a framework like grpc or...

This seems reasonable to me 👍