qos-ch / slf4j

Simple Logging Facade for Java
http://www.slf4j.org
MIT License
2.32k stars 980 forks source link

slf4j doesn't work on the docker #410

Closed nodece closed 5 months ago

nodece commented 5 months ago

Right now, I'm working on the Apache Pulsar project, and migrating the slf4j to 2.0.12 from 1.7.36, but it always prints the following log:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

please see https://github.com/apache/pulsar/pull/22391, the GHA env is Ubuntu, we are using the testcontainers to run the integration test, and the test image is based on the alpine 3.9:

I'm not sure where the problem is, thanks for your time!

How to reproduce

docker run -it nodece/java-test-image bin/pulsar proxy
ceki commented 5 months ago

@nodece Please refer to https://www.slf4j.org/codes.html#StaticLoggerBinder

The first phrase is quite relevant:

This warning message is reported by slf4j-api version 1.7.x and earlier when the org.slf4j.impl.StaticLoggerBinder class could not be loaded into memory.

and also

If you are seeing this message, then you are NOT using slf4j-api version 2.0 or later but slf4j-api version 1.7.x or earlier.

In any case, this looks like a packaging issue and not an SLF4J issue.

nodece commented 5 months ago

From the logs, it does seem like what you said, I know this log looks like we are using the slf4j2-api 1.7.x or earlier, I ensure the lib includes slf4j2-api 2.0.12, not 1.7.x.

I'm using the same image running on a different OS, it has a different log, how to explain this behavior?

In the MacOS, which prints 2024-04-07T14:46:00,668+0000 [main] ERROR org.apache.pulsar.proxy.server.ProxyServiceStarter - Failed to start pulsar proxy service. error msg metadataStoreUrl must be provided, it works fine.

In the Ubuntu, Failed to start pulsar proxy service wasn't printed.

nodece commented 5 months ago

Add -verbose:class to the java command, and you can find where slf4j2 loads from.

There are some strange differences in the jars loaded on different platforms.

Thanks.

ceki commented 5 months ago

From the logs, it does seem like what you said, I know this log looks like we are using the slf4j2-api 1.7.x or earlier, I ensure the lib includes slf4j2-api 2.0.12, not 1.7.x.

It does not seem, it is that you are using slf4j 1.7 or earlier.

I'm using the same image running on a different OS, it has a different log, how to explain this behavior?

You have a copy of slf4j-api version 1.7 somewhere else on you class path. As slf4j developers, we cannot investigate issues specific to your environment.