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.

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

Wrong classname when using slf4j inside a wrapper and logging via LoggingEventBuilder #409

Closed
MzrW opened this issue Apr 6, 2024 · 6 comments
Assignees
Labels
DONE for fixed issues
Milestone

Comments

@MzrW
Copy link

MzrW commented Apr 6, 2024

I am using the kotlin-logging library which is basically a wrapper around slf4j tailored for kotlin. (Original issue kotlin-logging-416).

When logging using the LoggingEventBuilder and setting the CallerBoundary accordingly it prints the wrong classname.

package my.pkg;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.spi.CallerBoundaryAware;

public class Example {
    private static final LoggingWrapper wrapper = new LoggingWrapper();

    public static void main(String[] args) {
        wrapper.logWithEvent("hello");
    }
}

class LoggingWrapper {
    private Logger underlyingLogger = LoggerFactory.getLogger("anything");

    public void logWithEvent(String msg) {
        var builder = underlyingLogger.atInfo();
        // setting the caller boundary to LoggingWrapper
        if(builder instanceof CallerBoundaryAware)
            ((CallerBoundaryAware) builder).setCallerBoundary(LoggingWrapper.class.getName());
        builder.log(msg);
    }
}

Running the given example I expect the following output:

Apr. 06, 2024 6:28:12 AM my.pkg.Example main
INFORMATION: hello

However following is printed:

Apr. 06, 2024 6:28:12 AM my.pkg.LoggingWrapper logWithEvent
INFORMATION: hello

Checkout the example: example.zip

m-waser pushed a commit to MzrW/slf4j that referenced this issue Apr 8, 2024
m-waser pushed a commit to MzrW/slf4j that referenced this issue Apr 9, 2024
Signed-off-by: Moritz Waser <mzrw.dev@pm.me>
m-waser pushed a commit to MzrW/slf4j that referenced this issue Apr 9, 2024
Signed-off-by: MzrW <mzrw.dev@pm.me>
@ceki ceki self-assigned this Apr 9, 2024
@ceki
Copy link
Member

ceki commented Apr 12, 2024

Linked to SLF4J-601 jira issue

@ceki
Copy link
Member

ceki commented Apr 12, 2024

@MzrW Thank you for reporting this issue and the accompanying PR.

I have made several changes inspired by your PR without merging it. Please provide your full name so that you can be given credit.

In any case, the issue is fixed in commit 3386517 part of slf4j version 2.0.13 released today.

@ceki ceki added this to the 2.0.13 milestone Apr 12, 2024
@ceki ceki added DONE for fixed issues and removed IN_PROGRESS labels Apr 12, 2024
dongjoon-hyun added a commit to apache/spark that referenced this issue Apr 16, 2024
### What changes were proposed in this pull request?

This PR aims to upgrade `slf4j` to 2.0.13.

### Why are the changes needed?

To bring the following bug fix,
- https://www.slf4j.org/news.html#2.0.13
  - qos-ch/slf4j#409

### Does this PR introduce _any_ user-facing change?

No.

### How was this patch tested?

Pass the Cis.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #46067 from dongjoon-hyun/SPARK-47861.

Authored-by: Dongjoon Hyun <dhyun@apple.com>
Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
@MzrW
Copy link
Author

MzrW commented Apr 16, 2024

@ceki Thank you for the fix, I could verify it's working properly.
My full name is Moritz Waser.

@MzrW
Copy link
Author

MzrW commented Apr 16, 2024

fixed in version 2.0.13

@MzrW MzrW closed this as completed Apr 16, 2024
@ceki
Copy link
Member

ceki commented Apr 17, 2024

I added your name in https://www.slf4j.org/news.html#2.0.13

By the way, compliments on your PR. Excellent work.

@m-waser
Copy link

m-waser commented Apr 18, 2024

thank you :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DONE for fixed issues
Projects
None yet
Development

No branches or pull requests

3 participants