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
