Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Optional call stack depth parameter #180

Open
MFlisar opened this issue Oct 23, 2016 · 6 comments · May be fixed by #362
Open

Optional call stack depth parameter #180

MFlisar opened this issue Oct 23, 2016 · 6 comments · May be fixed by #362

Comments

@MFlisar
Copy link

MFlisar commented Oct 23, 2016 •
edited

The logging interface looks like following:

log(int priority, String tag, String message, Throwable t)

Why not add an additional call stack adjustment value?

Use cases

Maybe someone wants to write reuseable logging functions, that should log their calling functions parameters. Seems like a common use case for me.

Example - simple transformer for logging observables execution time

public static <T> Observable.Transformer<T, T> applyMeasurement(Class clazz, String tag, boolean enabled)
{
    return observable -> measure(observable, clazz, tag, enabled);
}

private static <T> Observable<T> measure(Observable<T> observable, Class clazz, String tag, boolean enabled)
{
    if (!mEnabled || !enabled)
        return observable;

    LongHolder start = new LongHolder(0);
    return observable
            .doOnSubscribe(() -> start.set(System.currentTimeMillis()))
            .doOnTerminate(() -> Timber.d("[%s | %s] Duration: %dms", clazz, tag, System.currentTimeMillis() - start.get()));
}

Here the log would print the line and class of my logger utility class, which is not perfect...

Wouldn't it make sense to extend the log interface for such use cases?
@vaughandroid
Copy link

It's not entirely clear what you're asking for here. What might this "call stack adjustment value" look like?

If I'm understanding your use case correctly, you'd like to be able ignore/override the default tags created by the DebugTree class? You can already do this by writing a custom Tree implementation - you aren't forced to use DebugTree.

@MFlisar
Copy link
Author

MFlisar commented Feb 1, 2017

I want this parameter to be adjustable:

https://github.com/JakeWharton/timber/blob/master/timber/src/main/java/timber/log/Timber.java#L580

I want tags, I want calling function name, but I want to write functions that I call in my code. So the real interesting line and class in my code is the CALLER of my own function, this means, the CALL_STACK_INDEX should be increased by one for this case...

I've solved that anyways already by handling a correction value the same way as a custom tag value...

@drewhamilton drewhamilton mentioned this issue Apr 16, 2018
Closed
@drewhamilton drewhamilton linked a pull request Mar 19, 2019 that will close this issue
Open
@ammargitham
Copy link

Any chances the linked pull request will be merged? Seems to be open for 2 years now.

@TurKurT656
Copy link

This is very needed. I use top level functions that wraps the Timber methods.

@MFlisar
Copy link
Author

MFlisar commented Feb 9, 2022 •
edited

This issue is a few years old - if someone needs this feature and maybe even more, feel free to use my library or to copy the base tree inside it:

https://github.com/MFlisar/Lumberjack/blob/master/library/src/main/java/timber/log/BaseTree.kt

@TurKurT656
Copy link

Actually I've added an ability to the DebugTree to support this feature. I'll open a pull request

ammargitham added a commit to ammargitham/synergy-android-7 that referenced this issue Feb 10, 2022
@ammargitham
[Timber] Add support for additional log levels like debug1, debug2, etc.
d13a58b 
Currently Timber does not allow overriding the fqcnIgnore list from DebugTree (see JakeWharton/timber#180).
The source code has been copied locally and modified to allow overriding the list and renamed the log methods to avoid clash with the new extension functions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Allow additional ignored classes when inferring tags in DebugTree drewhamilton/timber
4 participants
@MFlisar @vaughandroid @TurKurT656 @ammargitham