What is the classloader structure for Exporters pulled in by the auto instrumentation?

[jsuereth]

I'm trying to make sure the Google Cloud auto exporters align with the direction the community has taken the past few months around classloaders, shading and stability.

Specifically:

1. Do we have the parent-child classloader relationship documented for -Dotel.exporter.jar? I'd like to know what I need to shade on my end to avoid possible conflicts with shared classes between exporter + agent jar. AFAIK exporters are loaded in their own classloader, but I was curious if you're using a filtered-parent for JUST the API/SDK or just "everything in the agent".
2. Are the rules on shading for my jar? Right now we're just bundling everything into the fat jar. I'd be happy to reduce the size by NOT including the API/SDK though :)
3. My exporter takes a dependency on gRPC + protobuf 3.0. I can shade/rename these in addition to bundling, but wanted to check if that's mandatory or not based on the classloader design of the agent.

Also, let me know if I should be asking this in a different repository. I'm asking here as I was hoping the documentation for "Implementing an Exporter" would live near the SDK interface for it, but I can move this to the java-instrumentation repo.

[jkwatson]

Hey Josh...this is probably a topic for the instrumentation repository. :). https://github.com/open-telemetry/opentelemetry-java-instrumentation/discussions

[jsuereth]

That answers the last question :)

[jsuereth]

Moved: open-telemetry/opentelemetry-java-instrumentation#2187

DO I close this one? Can you close this?

[jkwatson]

It can be deleted if you want to delete it.