More stable selection of exporter to use

[iNikem]

Isn't it quite normal to use the fully qualified class name when selecting an SPI implementation? SDK currently uses the approach too. It's guaranteed to be unique based on the nature of a Java classpath, while a name provided by a method has chances of collision which seems like something we don't want to deal with.

Having a hard-coded mapping from a short name to the fully qualified name for well-known implementations in the agent like otlp, logging, jaeger and zipkin seems like it could also provide the simpler UX without the risk of conflicting names from random exporters on the classpath.

Originally posted by @anuraaga in open-telemetry/opentelemetry-java#1332 (comment)

[iNikem]

I like both options from the comment above:

• Select exporter by fully classified name of its factory
• Have hard-coded mapping of short names to factories

I probably would favour the second option, it is more user-friendly.

[trask]

👍 to the user-friendly option

[anuraaga]

To clarify, I didn't mean to necessarily have to pick between two options :) We can accept both a fully qualified name (will be useful for people shading their own agent binary with a potentially custom exporter) and the short one for well known exporters to have and eat the cake

[anuraaga]

While talking about classifiers had a new thought. Instead of a set of short names, we don't really need any short names. How about automatically activating an exporter based on the presence of the endpoint flag, like ota.otlp.endpoint, ota.zipkin.endpoint? Currently we only load one exporter but it'd actually be sort of nice if we could just go ahead and enable all the exporters that users set the endpoint for.

Well, looking at the original post again this doesn't work for logging :) But ota.logging.file=stdout or /var/log/ota.txt could be a nice option too. ota.logging.enabled for special exporters that don't need options like endpoints can work. And gives us the power of multiple exporters

[trask]

Instead of a set of short names, we don't really need any short names. How about automatically activating an exporter based on the presence of the endpoint flag, like ota.otlp.endpoint, ota.zipkin.endpoint? Currently we only load one exporter but it'd actually be sort of nice if we could just go ahead and enable all the exporters that users set the endpoint for.

I like this proposal.

Also, it addresses this part of #385:

We currently only support a single exporter jar, so how does someone use jaeger + prometheus?

[iNikem]

And #496

[trask]

Does it make sense to close this issue and move the proposal over to #496?

[trask]

Closing, moved above proposal over to #496