We have a similar need (#13961).

However, in our case we do not care about the specific server instrumentation. in our case we would like to have a header getter injected.

Open questions:

• currently we decide whether to customize based on the instrumentation name. This may not let us distinguish between different instrumenters that are part of the same instrumentation e.g. armeria client and server. We could provide a dynamic check that could expose original span name and kind. Or we could use the span suppression keys (the ones that we get from the extractors) to expose what kind of instrumenter we are dealing with.
• request and response are Objects that can only be used via reflection (even if you have the class you can't cast because of different class loaders).
• more customizations, e.g. do we want to allow changing span kind?
  cc @trask

• currently we decide whether to customize based on the instrumentation name. This may not let us distinguish between different instrumenters that are part of the same instrumentation e.g. armeria client and server. We could provide a dynamic check that could expose original span name and kind. Or we could use the span suppression keys (the ones that we get from the extractors) to expose what kind of instrumenter we are dealing with.

I think it's necessary to support distinguishing the type of instrumenter in same instrumentation. I are willing to explore related solution later. How about supporting it in a follow-up PR and providing current abilities for users firstly? I have refactored our inner Distro recently, I might need a bit more time to get started.

• request and response are Objects that can only be used via reflection (even if you have the class you can't cast because of different class loaders).

Sorry, I am not very clear about this point. Could you elaborate more about its background or purpose?

• more customizations, e.g. do we want to allow changing span kind?

For this point, In fact, I haven't encouraged related requirement so far. I can file an issue to contain it and point one and set corresponding order. We could support them by order and requirement?

I created a follow-up issue to track above potential requirements #14424

I think it's necessary to support distinguishing the type of instrumenter in same instrumentation. I are willing to explore related solution later. How about supporting it in a follow-up PR and providing current abilities for users firstly? I have refactored our inner Distro recently, I might need a bit more time to get started.

sure we can do it later

• request and response are Objects that can only be used via reflection (even if you have the class you can't cast because of different class loaders).

Sorry, I am not very clear about this point. Could you elaborate more about its background or purpose?

Instrumentations are usually loaded into the class loader that hosts the instrumented library, but customizer is in the agent class loader. Lets assume that you are trying to customize apache http client 5.0 In https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/apache-httpclient/apache-httpclient-5.0/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/apachehttpclient/v5_0/ApacheHttpClientHttpAttributesGetter.java request is org.apache.hc.core5.http.HttpRequest When using the agent in the attribute extractor that you add from the customizer you won't be able to use HttpRequest because your extractor is in the agent class loader and can't see that type so you'd have to use reflection.

Instrumentations are usually loaded into the class loader that hosts the instrumented library, but customizer is in the agent class loader. Lets assume that you are trying to customize apache http client 5.0 In https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/apache-httpclient/apache-httpclient-5.0/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/apachehttpclient/v5_0/ApacheHttpClientHttpAttributesGetter.java request is org.apache.hc.core5.http.HttpRequest When using the agent in the attribute extractor that you add from the customizer you won't be able to use HttpRequest because your extractor is in the agent class loader and can't see that type so you'd have to use reflection.

Make sense! That is really a limitation for usage. There doesn't seem to be a good way to solve it. Is it necessary to highlight this point in the related example documentation?