Should Trace Propagators define ConfigurablePropagatorProviders?

[kenfinnigan]

Currently, the AWS propagator implements ConfigurablePropagatorProvider from the AutoConfigure SPI, providing a convenient way for a propagator instance to be retrieved.

Is there any reason why the propagators in https://github.com/open-telemetry/opentelemetry-java/tree/main/extensions/trace-propagators don't define a ConfigurablePropagatorProvider for Jaeger, OTTracer, and B3?

As B3 has two types, it might require two providers. Beyond this, I'm not sure if there's a particular reason they're implemented differently?

[jkwatson]

Mostly, we don't want our stable propagators to depend on unstable auto-configuration code.

[kenfinnigan]

@anuraaga I was looking at implementing the ability to configure the propagators for Quarkus without necessarily having a classpath dependency on the specific implementations.

For example, being able to depend on the AutoConfigure SPI for finding and retrieving an INSTANCE for a propagator, but then what's in the classpath is determined by the users' application.

[anuraaga]

Thanks - I sent #3294 since it seems fine to me. Should we extract autoconfigure-spi into a separate artifact by the way?

[kenfinnigan]

@anuraaga If the SPI was separate that makes things simpler, as you could depend on the SPI without any of the actual autoconfigure code itself

[anuraaga]

Looked into extracting out the SPI - had a problem in that the SPI depends on ConfigProperties and ConfigurationException class. This seems to have two problems that

1. We'd need to include these non-SPI classes in the SPI. A bit weird
2. A different configuration mechanism like Quarkus presumably doesn't want to use ConfigProperties

@kenfinnigan Any thoughts on a good way to separate out the SPI?

[kenfinnigan]

@anuraaga I took a look at the code and I see there are a couple options:

1. Have ConfigProperties and ConfigurationException be a part of the SPI, as they're "required" for the SPI to work
2. Create an interface for ConfigProperties, which is part of the SPI, and the other SPI interfaces use, and then ConfigProperties implements it. This approach means ConfigurationException is only utilized within ConfigProperties and is not needed in the SPI