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

slf4j-jdk-platform-logging always logging Level.ALL messages regardless of logger level #430

Closed
peterhalicky opened this issue Sep 16, 2024 · 8 comments
Assignees
Labels
DONE for fixed issues
Milestone

Comments

@peterhalicky
Copy link

peterhalicky commented Sep 16, 2024

So, sun.security.ssl.SSLLogger logs its finest events with Level.ALL. While that on its own is a bug (and I reported it), I'd say slf4j-jdk-platform-logging is still handling it incorrectly. It gets written out as TRACE level, regardless of level setting of the logger.

I'm all for treating the Level.ALL as TRACE, but it should also be filtered as such. I suppose in SLF4JPlatformLogger.log(...) method instead of current:

        if (jplLevel == Level.ALL) {
            performLog(org.slf4j.event.Level.TRACE, bundle, msg, thrown, params);
            return;
        }

it should be:

        if (jplLevel == Level.ALL) {
            if (slf4jLogger.isEnabledForLevel(org.slf4j.event.Level.TRACE)) {
                performLog(org.slf4j.event.Level.TRACE, bundle, msg, thrown, params);
            }
            return;
        }

I will gladly submit a PR if this looks okay to the relevant people here.

@ceki
Copy link
Member

ceki commented Sep 20, 2024

@peterhalicky As you mention, it is quite incorrect to log with the Level.ALL which is below Level.FINEST/TRACE. it is means that all logs should be allowed. I agree with your assessment regarding filtering using Level.TRACE. I was probably confused regarding the meaning of Level.ALL when writing the code below:

private void log(Level jplLevel, ResourceBundle bundle, String msg, Throwable thrown, Object... params) {
        if (jplLevel == Level.OFF)
            return;

        if (jplLevel == Level.ALL) {
            performLog(org.slf4j.event.Level.TRACE, bundle, msg, thrown, params);
            return;
        }
   ...

@ceki
Copy link
Member

ceki commented Sep 21, 2024

@peterhalicky Fixed in commit f7b34c2. Let me know what you think.

@ceki ceki closed this as completed Sep 21, 2024
@peterhalicky
Copy link
Author

@ceki I'm not sure if I agree with mapping the Level.OFF level to Level.ERROR -- which in most typical configuration will be written to the log; I'd guess if someone logs with Level.OFF, he probably means to never actually write it in the log -- so if not dropping the message completely I'd probably instead map it to Level.TRACE (kinda same as Level.ALL, which is counterintuitive -- but it's counterintuitive to actually use those levels anyway).

@ceki
Copy link
Member

ceki commented Sep 21, 2024

Indeed, Level.OFF and Level.ALL are a quite counter intuitive when used as logging levels.

However, no one is supposed to use Level.OFF and Level.ALL for logging. They are intended for filtering and are vestigial from log4j 1.x where it was possible to subclass Level to create custom levels. In logback and log4j2 the Level class is final. Thus, Level.ALL makes little sense while Level.OFF can be used to filter out all logging.

Also, Level.OFF has the highest priority (not the lowest). Level.ALL has the lowest priority (not the highest).

@peterhalicky
Copy link
Author

What I'm worried about is that when someone non-sensically uses Level.OFF for logging and we map it to Level.ERROR, it will be difficult to get rid of those messages.

@ceki
Copy link
Member

ceki commented Sep 21, 2024

On the contrary, in that case, you would assign the level of the logger to Level.OFF and the message would not be print (which is the desired outcome).

@peterhalicky
Copy link
Author

Well, but if the logger is actually logging something useful at Level.INFO, WARN or ERROR, we'd miss that.

@ceki
Copy link
Member

ceki commented Sep 21, 2024

With only the logger-level filter, it is impossible for a logger to simultaneously suppress messages of Level.ERROR and allow messages of Level.WARN. When Level.OFF is mapped to SLF4J-Level.ERROR, you can at least suppress the message if you really wanted to.

@ceki ceki self-assigned this Feb 25, 2025
@ceki ceki added the DONE for fixed issues label Feb 25, 2025
@ceki ceki added this to the 2.0.17 milestone Feb 25, 2025
dongjoon-hyun pushed a commit to apache/spark that referenced this issue Mar 4, 2025
### What changes were proposed in this pull request?
This pr aims to upgrade slf4j from 2.0.16 to 2.0.17.

### Why are the changes needed?
The new version brings some bug fixes, like:

- As reported in qos-ch/slf4j#450, in some rare cases where MDC could be initialized before LoggerFactory. Thus, MDC would be stuck using the wrong MDCAdapter instance. To fix this issue LoggerFactory and MDC have been modified. Implementations of SLF4JServiceProvider are encouraged to initialize their mdcAdapter and markerFactory fields as early as possible, preferably at construction time. Note that these changes are transparent to existing logging backends which will continue to work as is.

- Fixed incorrect interpretation of Level.OFF and Level.ALL in SLF4JPlatformLogger by mapping Level.OFF as Level.ERROR and Level.ALL as Level.TRACE. This issue was reported in qos-ch/slf4j#430 by Peter Halicky.

The full release notes as follows:
- https://github.com/qos-ch/slf4j/releases/tag/v_2.0.17

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

### How was this patch tested?
Pass GitHub Actions

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

Closes #50115 from LuciferYang/slf4j-2.0.17.

Lead-authored-by: yangjie01 <yangjie01@baidu.com>
Co-authored-by: YangJie <yangjie01@baidu.com>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
Pajaraja pushed a commit to Pajaraja/spark that referenced this issue Mar 6, 2025
### What changes were proposed in this pull request?
This pr aims to upgrade slf4j from 2.0.16 to 2.0.17.

### Why are the changes needed?
The new version brings some bug fixes, like:

- As reported in qos-ch/slf4j#450, in some rare cases where MDC could be initialized before LoggerFactory. Thus, MDC would be stuck using the wrong MDCAdapter instance. To fix this issue LoggerFactory and MDC have been modified. Implementations of SLF4JServiceProvider are encouraged to initialize their mdcAdapter and markerFactory fields as early as possible, preferably at construction time. Note that these changes are transparent to existing logging backends which will continue to work as is.

- Fixed incorrect interpretation of Level.OFF and Level.ALL in SLF4JPlatformLogger by mapping Level.OFF as Level.ERROR and Level.ALL as Level.TRACE. This issue was reported in qos-ch/slf4j#430 by Peter Halicky.

The full release notes as follows:
- https://github.com/qos-ch/slf4j/releases/tag/v_2.0.17

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

### How was this patch tested?
Pass GitHub Actions

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

Closes apache#50115 from LuciferYang/slf4j-2.0.17.

Lead-authored-by: yangjie01 <yangjie01@baidu.com>
Co-authored-by: YangJie <yangjie01@baidu.com>
Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
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

2 participants