AbstractSpanBuilder.childOf should not return NoopSpanBuilder about opentracing-java

[michaelsembwever]

I expect that a child of a "no span" (or NoopSpan, or null) is just a span without a parent.

This is the false premise (to the direction taken so far).
An empty context provides a noop span, and the child of a noop span is implicitly another noop span.
An explicit action is required to go from an empty context to an empty (rather than noop) span.
This is what provides the most fluent api for users.

Though it might be better to add SpanContext.isEmpty method to the API, make it explicit and get rid of this weird "instanceof".

I suspect this has a lot of merit. The current situation does lead to having to understand a number of complexities in the design and use patterns.

[mabn]

I do not follow...
When a request is received I want a span to start which will be tracked/reported no matter if the request(carrier) contains span context or not. In both these cases I'd like following code to work properly:

SpanContext parent = tracer.extract(Format.Builtin.TEXT_MAP, adapter);
Span span = tracer.buildSpan("some-name").asChildOf(parent).start())

But if empty context provides a noop span, then I'll need some conditional like:

SpanContext parent = tracer.extract(Format.Builtin.TEXT_MAP, adapter);
SpanBuilder builder = tracer.buildSpan("some-name");
Span span;
if(parent is empty-context) {
   span = builder.build(); // can't use asChildOf because it will create NoopSpan and I don't want it
} else {
  span = builder.asChildOf(parent).build();
}

Do I understand this correctly?

[michaelsembwever]

This is in a direct contradiction to the changes done in #56 ("A child of a NoopSpan is a NoopSpan"), but I believe that the behaviour introduced there is not correct.

FTR i think it'll be more constructive focusing on discussions that happened in #58

But if empty context provides a noop span, then I'll need some conditional like…

That is correct.
The premise is that in any decent sized microservices platform the majority of services do not force sampling/tracing, that they only continue tracing requests that are already being traced. This would also be the default approach when adding tracing to libraries and frameworks. For more info see #58 (comment)

[bhs]

@michaelsembwever as has been demonstrated in other OT language implementations, there is no need for this sort of conditional as long as asChildOf (and followsFrom) are documented to accept the empty/null/whatever SpanContext... I feel rather strongly that we should allow the user to just write

span = builder.asChildOf(parentContext).build();

regardless of whether parentContext is an EmptyContext or null or whatever we've agreed is most appropriate in modern Java.

[michaelsembwever]

span = builder.asChildOf(parentContext).build();

They can. The discussion here is to whether tracing off an empty context here is implicitly forced or not. My argument in #58 (comment) is that you can easily save yourself hundreds or thousands of lines of code by not implicitly forcing tracing.

Both side of the argument though clarify the need for a better mechanism, like spanContext.isEmpty() to exist.

[mabn]

@michaelsembwever I've read #58 discussion - it makes sense for it to behave like you described.

But if it's a part of some instrumented framework you'll still need some extra code to decide if this the instrumented service is the service which starts traces or not.

It would be ideal if the same construction (builder.asChildOf(parentContext).build()) could be used in both cases and the behaviour explicitly configurable (via sampling policy?).

[michaelsembwever]

It would be ideal if the same construction (builder.asChildOf(parentContext).build()) could be used in both cases and the behaviour explicitly configurable (via sampling policy?)

Agreed. And it's been previously discussed and agreed upon :-)

[tedsuo]

Spring cleaning here: closing this issue as it is out of date. Feel free to reopen or create a new issue if you'd like to continue.