Allow additional ignored classes when inferring tags in DebugTree

[drewhamilton]

Fixes #180 on a per-Tree basis.
Replaces #314 given the new internal tag-determination logic.

Add DebugTree#ignoreForTagging(Class) to allow more classes to be ignored when the tag is inferred from the stacktrace. This is useful for anyone needing to wrap Timber, e.g. for use in a Java-only module.

Also changes fqcnIgnore from a list into a set because only its contains method is used.

[yhartanto]

Do we need to add the additional exception list post instantiation? Might be better to just offer a constructor param to allow consumer send class list, that way the list can be immutable still.

From a consumer perspective, typically you initialize Timber once and don't touch it again.

[yhartanto]

open class DebugTree(vararg ignoredClasses: Class<Any>) : Tree() {
    private val fqcnIgnore =  listOf(
        Timber::class.java.name,
        Timber.Forest::class.java.name,
        Tree::class.java.name,
        DebugTree::class.java.name
    ).plus(ignoredClasses)

[drewhamilton]

Yeah, that's a better API. Happy to update if there's interest in merging this feature.

[tpucci]

I am very interested by this :)

[yhartanto]

Yeah me too. 👍

[drewhamilton]

Converted to a constructor parameter. The semantics are a bit weird now though: it's not obvious when reading DebugTree(SomeClass::class.java) that the tree would ignore "SomeClass" for tags. I wonder if a static factory like DebugTree.withIgnoredClasses would be more appropriate.

[yhartanto]

Converted to a constructor parameter. The semantics are a bit weird now though: it's not obvious when reading DebugTree(SomeClass::class.java) that the tree would ignore "SomeClass" for tags. I wonder if a static factory like DebugTree.withIgnoredClasses would be more appropriate.

I think that is a valid consideration, we can add a static factory to make the API more explicit.

[TurKurT656]

What if we wrap Timber logs inside kotlin top level functions?

LogExtension.kt:

fun logD("message") {
    Timber.d(message)
}

Then if we want to ignore it we do not access to the class. However there is an auto generated class named LogExtensionKt that is hidden from kotlin files. So what we can do about it?
Maybe if we accept ignored classes as strings we can solve this problem but I'm not sure if its a good thing to do.

[Chesteer89]

Any update on this?

[dyguests]

Any update?

[dyguests]

alternative plan

https://github.com/dyguests/timber/releases/tag/5.0.1.1

[realbarisbasturk]

I encountered the same issue. I wanted to wrap Timber in a separate logging module and inject it with Hilt wherever necessary. Since the PR has been open for almost six years now, I ended up writing a small logging class myself. However, I’d love to see this get merged so I can replace my implementation.