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 > > >
