>From conversations I've had over on the otel slack, it seems that all we really need to do is make sure that there's a "current" span when handing flow control over to user code.
On Mon, Nov 15, 2021 at 6:15 PM Andrew Purtell <apurt...@apache.org> wrote: > If the exposure is for/within coprocessors, I think that usage falls under > the same exception we make for LimitedPrivate and other things that are > necessary for server internal extension but are not public API either. > > > On Tue, Nov 9, 2021 at 4:04 PM Nick Dimiduk <ndimi...@apache.org> wrote: > > > Let me find some clarification on what/how might be exposed. > > > > On Tue, Nov 9, 2021 at 3:34 PM 张铎(Duo Zhang) <palomino...@gmail.com> > > wrote: > > > > > 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 > > > > > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
