Register global only if absent

[danielgblanco]

We're starting to work on our migration from OpenTracing to OpenTelemetry (initially via shims). Internally, as support multiple engineering teams, we provide a set of internal common libraries across our supported frameworks that deal with setting up various features, including tracing. In Java, using GlobalTracer.registerIfAbsent() played quite nicely with integration tests in apps using these common libs (developers don't need to have knowledge of how the tracer is setup). I'm aware that the OpenTelemetry API provides a GlobalOpenTelemetry.resetForTest() for this specific use case (integration tests), but I wonder if there have been discussions (I've not found any) to do something similar and only register if absent in buildAndRegisterGlobal() or a separate method, and why that was not decided as the best way forward.

[jkwatson]

Hello @danielgblanco . We did consider this option, but considered it potentially more confusing to silently ignore the user's inputs, rather than telling them explicitly that something was not right. And, for testing, we chose to make it explicitly a testing method, rather than a part of the "normal" API.

If you have a non-testing use-case where it is necessary to have multiple global-registrations, we'd be happy to consider adding a new method for that. But, in those cases, I think we would strongly encourage users to simply not use the global at all, and maintain their own "global" state if they need it.

[danielgblanco]

Thanks, that makes complete sense. I guess our use case is quite custom. We provide a Dropwizard bundle as part of our common libs that takes care of configuring the global OTel instance so that it points to the right collectors within our infra, uses the right propagators, etc. The idea is that developers that use these libs only have to interact with the OTel API for custom cases, and in that case everything is pre-configured.

I don't think many of our apps would have tracing enabled during integration tests, but if the do and we roll out an upgrade to these libs to include OTel shims, it'd make their integration tests fail between resets when the bundle is re-run (unless they manually call resetForTest). We have opted for keeping an atomic boolean in the bundle to indicate it has been initialised, and log a warning message the second time the bundle is initialised, keeping the same OTel instance registered.