How to avoid conflicts between LD's Timber logs and our own app's Timber logs? #147
Description
Is your feature request related to a problem? Please describe.
Our app uses Timber for logging, and have a custom Tree that sends exceptions from Timber.w() and Timber.e() calls into our error reporting system. Our team noticed some strange errors in our system and eventually realized that these were originating within the LD SDK (Here's one example, ultimately resulting from the Timber usage in LDConfig here).
How should we avoid the discrepancy between LD's own Timber logging Tree and our own?
Describe the solution you'd like
There's a few different solutions that come to mind. I'm curious if you all have thoughts on any of them, or if anyone else has run into a similar issue?
- Preferably, LD would use its own logging abstraction and minimize its 3rd party dependencies (but Timber is useful so I see the benefit of using it). LD could also pull in the Timber class files themselves and include them in the SDK (but renamed) to avoid the conflict.
- We could also do the example same thing on our side, which is equally reasonable.
- We could update our custom Timber
Treeto try and ignore logs that originated from Trees that we don't own.
Describe alternatives you've considered
Logging within our app via a completely different method (which we're not opposed to).
Additional context
N/A