Construction by dependency injection / excessive reliance on static singletons

[jacostro]

Hello,
I'm currently trying to switch my project which was based on OpenCensus to OpenTelemetry. This is an exercise in frustration, because apparently there is no way to make my existing tests work - thanks to improved protection of classes, constructors and methods by internal keyword. I'm not able to find a way to initialize stats component in isolation - it seems that the only way is to use static properties of Stats class, and I need a fresh state for each test. (Previously it was possible by instantiation of StatsComponent class.)

What about more flexible composition by dependency injection? I can see some reasons why this would be better:

• external test scenarios involving OpenTelemetry components (my case),
• possibility to create multiple instances of OpenTelemetry classes with separate configurations,
• more flexibility with regards to component implementation,
• option to reinitialize the stats / trace subsystem,
• nice integration with .NET (Core) applications which already heavily rely on DI.

It could be still possible to perform initialization of (for example) stats subsystem by explicit instantiation of Stats class, with reasonable default configuration. Currently even if I remove constructor protection by internal keyword it won't help much, because the properties are static.

[lmolkova]

We are doing some changes that mostly eliminated static singletons in Tracing API. There will be global tracer, but you'll have control to set it.

Metrics/Tags everything else will get similar treatment in the next month or two.

Overall, we want to minimize static singletons usage and allow users to completely avoid them when possible.