Sjoerd Talsma

Drive-by comment, use as you wish. This feature probably won't stop at maintaining a span, as people will now start to expect that spans activated in one of the callbacks...

@thegreystone I like the decorator idea and I think it has come up before. However, as I understand it, each tracer can currently assume that all spans are 'their own'....

> decorator can never know, whether scope was actually closed or not Don't let that influence the listener vs. decorator discussion please. If that's a 'defect' of the current scope...

Please note there is a bit of discussion in [PR 211](https://github.com/opentracing/opentracing-java/pull/211) about the desirability of adding this to the API

As far as I recall it was an intentional decision to remove (Auto-)`Closeable` from the `Span` interface because it invites the _try-with-resources_ paradigm which actually makes it easy to forget...

@mabn I like this idea (I think you mentioned it on the old globaltracer project before). I assume to work with java < 8, we need to define a single-op...

>ATM, I think this is not defined anywhere. Why is it allowed at all to call finish multiple times? Undefined != forbidden. The spec says calls after `finish` have undefined...

The GlobalTracer -by design- only exposes the OpenTracing API. This has the advantage that you're guaranteed of it functioning correctly and discourages people working around it by typecasting. Technically it...

> My two cents: Don't use `GlobalTracer` at all. Accessing it using dependency injection makes for so much cleaner and more sane code. Yes, I completely forgot go mention this...

FYI, I have identified a need for a similar concept in my context-propagation library: https://github.com/talsma-ict/context-propagation/blob/develop/context-propagation-java5/src/main/java/nl/talsmasoftware/context/observer/ContextObserver.java