[Discuss] Tracer is just interface, is it enough? I think it make users difficult to switch implements.

[wu-sheng]

@bensigelman @yurishkuro @michaelsembwever
As OpenTracing specification says, one of OpenTracing specification goals is to let application developers to build trace in their application from beginning, and to choose implements later.
I review the api module recently. I think the definition of interface Tracer may cause users difficult to switch implements.

First, if I am a application developers, in order to use OpenTracing-api, I must new TracerImp(). At this time, I must choose a implements to make sure the "new" can be done. This don't match the specification obviously.

Other way to do this, I must import opentracing-impl or opentracing-noop module, and new NoopTracer() instead. It seems to work. But I am define a tracer many times, when I develop distributed system. When I switch implement to a real tracer, I must change all codes refer to this new operation. It seems not so cool.

I recommend to change add a TracerFactory or TracerResolver, to choose a tracer Implment base on some tech. Such as spi, System.getProperty() (use -D main param). TracerFactory or TracerResolver will return the noop-implements in opentracing-noop module.
Or TracerFactory or TracerResolver provide register operation to let implements to do

What's your opinions about this?
If you agree with me, I will send a pull request to provide this api.

Looking forward your replies.

[yurishkuro]

adding an extra layer of indirection via "tracer factory" does not resolve your issue of having to make a decision about the implementation and have some way of representing that decision in every service in your system.

I think a more realistic approach is to give all services in your ecosystem a shared library that will be responsible for instantiating a specific implementation of the tracer. You could implement the initialization logic with a factory as you described, if you wish, but each initialization will be fairly specific to the concrete tracer implementation. For example, to create a Jaeger Tracer you need to instantiate and pass certain parameters (sampler, reporter, etc), so doing it via -D properties is not very easy to generalize.

[wu-sheng]

A shared lib seems a way to go for one, who focus on developing system.

But, as a tracer sky-walking develop, I focus on the easiest way to integrate tracer system to app.

As java tracer, the most popular tech is javaagent, by using premain and instrument. In this way, I want to achieve the goal by following OpenTracing Specification: Application developer choose to follow OpenTracing API, but not choose implements. And this system is running on dev env, with noop-impl. When system on line( test or production env), choose a tracer system, use -javaagent to instrument..

No source code need to change. I think this is very import for tracer and system developer.

It seems necessary for you or OpenTracing-java?

[yurishkuro]

I still think the problem you're trying to solve (a) has many different solutions, javaagent being one of them, and (b) is a problem of packaging, dependency injection, deployment. It's not a problem that OpenTracing API itself is trying to solve. I would suggest starting with a personal repository, something like yourname/opentracing-javaagent, developing a prototype there with examples of integrating the app with 2-3 different implementations of OpenTracing (e.g. Jaeger, Lightstep, and there's zipkin/brave/opentracing bridge in the openzipkin project). If you succeed in such prototype, you can move it to the github.com/opentracing-contrib org as a utility package for binding tracing implementations.

[bhs]

I agree with @yurishkuro: that this is a fundamental software engineering issue that almost certainly can (and, thus, should) be resolved outside of the OpenTracing API itself.

[wu-sheng]

Thanks a lot. I will review the openzipkin/brave-opentracing first, and decide what to do next. And prepare sky-walking to follow opentracing specification.

If I have more questions, I will let you known. Thanks, again.