What does ‘expose’ actually mean here? I think a typical usage is that, users create a span and a scope, and in the scope they call our client API, and our client API will make use of the Span in the current scope?
So at least we need to let users know they have to use otel if they want to trace HBase calls. But do we really need to expose other things? Thanks. Sean Busbey <bus...@apache.org>于2021年11月10日 周三05:40写道： > If it was akin to slf4j, that integration has been relatively smooth > for downstream. > > log4j effectively being in our public api through configuration > formats has been a maintenance nightmare. > > These would effectively be in our java binary API though, right? Would > we gain any meaningful isolation from trouble later on if we had > wrapper objects around the otel stuff? > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk <ndimi...@apache.org> wrote: > > > > Heya, > > > > I've been kicking the tires on the OpenTelemetry tracing work and I have > an > > ugly question to present. One of the things suggested by the otel > community > > is that library implementers (like us, with hbase-client) expose the > > Span/Scope objects to callers so that they can add context annotations. I > > think this means adding API calls that return otel instances. From our > > previous experience exposing Guava objects in our API, this sounds no > good. > > On the other hand, log4j and SLF4j are effectively in our public API, and > > so maybe otel is of a similar breed. > > > > I have not yet attempted to implement exposure of their objects in our > > client API, so as of now, my position is that of speculation. I'll report > > back as I make progress in this direction. If anyone else has already > > traveled this road, please speak up and share your experiences. > > > > Thanks, > > Nick >
