Mateusz Rzeszutek

> I don't think this is Java-specific at all. This is a problem for all SIGs that want to strongly type their attributes and also for the semantic convention generator....

> > Also, I know of no backend that supports maps for tracing. > > From what I understand AS X-Ray does: https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html#xray-concepts-annotations > > From the above link: >...

> allowing them to be set as either resource or span attributes. That would be perfect for all/most cloud/faas attributes. For example, if I wanted to add `cloud.account.id` on AWS...

Can somebody provide insight on how should we deal with the yaml files? Should I just duplicate the attributes in resources & traces?

Hey @metacubed, For simplicity (and faster development) we've ended up building our separate buildpack just for the agent, you can find it [here](https://github.com/signalfx/splunk-otel-java/tree/main/deployments/cloudfoundry/buildpack). Unfortunately we don't have time & resources...

Do you think this behavior is something we need just for resource attributes? Or maps in general?

With https://github.com/open-telemetry/opentelemetry-java/issues/4661#issuecomment-1226448819 in mind: perhaps we should move the AWS resource providers to the contrib repo (they pretty much require some internal AWS knowledge to maintain), and all OS/runtime/process resource...

Now that https://github.com/open-telemetry/opentelemetry-specification/pull/2789 was merged, should the `attributes` field be removed from `InstrumentationScopeInfo` `equals()`/`hashCode()` methods?

I created an issue about a similar topic: https://github.com/open-telemetry/opentelemetry-java/issues/4669 I did not think about the local IP changes though (well, I was only interested in not having it at all...

Hey, Sorry for being quiet, I was on vacation/sick leave for some time and this flew under my radar completely. I'll try to compile the files you requested tomorrow.