Trask Stalnaker

Most of the verification is done now in #12955, but there are still some TODOs in `check-javaagent-instrumentation-suppression-keys.sh` that need follow-ups.

my wish list would include changing the methods instrumentation to read its configuration from a yaml file (or wait until we have standard yaml file). e.g. I've also had interest...

@xiepuhuan that sounds great!

> 1. Use a fixed short and meaningful metric name. Example: `code.method.invocation.duration` I think we went away from this proposal in #11354, probably because: ["As a rule of thumb, aggregations...

@brunobat is there any corresponding incubating or internal API that needs to be deprecated (or was this never exposed at all)? is test coverage already complete for the feature? (also,...

thanks, I support stabilizing this feature

> Stabilizing this is blocked by the spec. This feature is still "in development" at the spec level: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#tracerconfigurator thanks, I got mixed up thinking this was about stabilizing instrumentation...

@brunobat go ahead and open a spec issue about stabilizing it, e.g. https://github.com/open-telemetry/opentelemetry-specification/issues?q=is%3Aissue%20state%3Aclosed%20stabilize%20in%3Atitle

This makes sense to me. As @lmolkova mentioned in Slack: > we're using host:port as a fallback on [DB](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-spans.md) and [messaging span names](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/messaging/messaging-spans.md#span-name) We'd just have to make this behavior...

Closing as this is being tracked now (along with other limits) at https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks