opened
jpkrohling
username_0
It's usually a good practice to have a loader (resolver, in this case) and a factory as different entities. This way, the loader can be extended or replaced and the factories would still work. This is specially important for an SPI, such as this one.

One concrete problem caused by the current approach is that one cannot easily provide a custom implementation of the `TracerResolver`, as current resolver (such as Jaeger's) extends the `TracerResolver` and exposes the tracer only via a `protected` method.

My proposal (pseudo code):

```java
public interface TracerFactory {
    Tracer getTracer();
}

public class TracerResolver {
  public static Tracer resolve() {
    ServiceLoader<TracerFactory> factories = ServiceLoader.load(TracerFactory.class);
    // iterators, disambiguation, ...
    return factories.iterator().next().getTracer();
  }
}

// factory example, very similar to current TracerResolver subclasses
public class JaegerTracerFactory implements TracerFactory {
  public Tracer getTracer() {
    return Configuration.fromEnv().getTracer();
  }
}
```
Split the resolver from the "factory"
issue
created
sjoerdtalsma
username_1
I think your idea is an improvement over the current resolver, which was intentionally as simple as possible.

One concern:  

1. Could we introduce such a `TracerFactory` interface in a backward-compatible way?  

Maybe let the current `TracerResolver` resolve both the new `TracerFactory` _and_ the current `TracerResolver` subclasses? 

I would like to create a release in which we document that people should implement a `TracerFactory` SPI but that allows them time to do so without existing instrumentations breaking by a simple `java-tracerresolver` library upgrade?
comment
closed
sjoerdtalsma
username_1
issue