Thanks Nick. This is also my understanding if I read your email correctly...
And could you please invite me into the OTEL slack channel? Thanks. Nick Dimiduk <ndimi...@apache.org> 于2021年11月17日周三 上午1:45写道： > > 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 > >
