We Keep Coding

Setting Hibernate Logging Provider with Version 6.1

I am using Hibernate 6.1.2. I'd like to log use the default JDK logging provider. According to a documentation for 5.4, this can be done like this:
public class TestSL4JBug {
public static void main(String[] args) {
System.setProperty("org.jboss.logging.provider", "jdk");
jakarta.persistence.Persistence.createEntityManagerFactory("myPersistence");
}
}
I looked for a similar explanation in newer documentations, but I did not find it.
Alas, if I am testing the minimal example above, I get this:
...
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.
MLog initialization issue: slf4j found no binding or threatened to use its (dangerously silent) NOPLogger. We consider the slf4j library not found.
...
To me, this looks like Hibernate tries to load SLF4J and fails. I have, of course, found guides that say I should add the SLF4J dependency, but that is not what I want.
So my question is: How do I configure Hibernate 6.1.2 to log with JDK logging? Has the property changed, or should I use a better way to set it?

I realized that it was not vanilla Hibernate that caused the error. I am also using hibernate-spatial and consequently geolatte-geom. That one is not using JBoss logging and instead always goes through SLF4J. So even though Hibernate went through JDK logging, SLF4J was still loaded. I have now unhappily added slf4j-jdk14 and the error is gone. It's still more layers and source code sources than I am happy with, but probably a lot less than in other programming ecosystems.

how to use slf4j in java agent when in spring boot

Springboot uses JarLauncher so that a nested jar is supported.
But the agent code do not load class by using JarLauncher because it executes before the main method.As a result, the console will print
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
--update
This issue can reproduce the problem.
https://github.com/libinglong/skywalking-threadpool-agent/issues/2

How to disable slf4j in jetty

I am using a self code logger and i dont want implement to slf4j.
And Jetty will prints:
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
How to disable this stupid output?
Im not using Spring or something like that. I just import jetty library and it prints...

Use a slf4j-nop logger
Add this in dependencies block of build.gradle
kotlin DSL:
implementation("org.slf4j:slf4j-nop:2.0.0-alpha1")

SLF4J Defaulting to Log4j over logback even when binding doesn't exist

I am trying to get SLF4J to bind to logback, but it is instead defaulting to Log4j.
I have all the default config files configured for logback, as well as the bindings.
My classpath has the following relevant jars:
logback-classic
commons-logging (99.0-does-not-exist) //empty jar to exclude commons-logging
logback-core
logback-ext-spring
Note: No log4j dependencies are present.
This is a spring mvc app.
On startup SLF4J has the following output:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/masierp/Documents/springsource/vfabric-tc-server-developer-2.8.2.RELEASE/blablahbkla/wtpwebapps/ilm-engine/WEB-INF/lib/activemq-all-5.7.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/masierp/Documents/springsource/vfabric-tc-server-developer-2.8.2.RELEASE/blablahbkla/wtpwebapps/ilm-engine/WEB-INF/lib/logback-classic-1.1.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Note that none of the found bindings are log4j bindings.
I have messed with spring-ext (trying to use it as the spring listener) but with or without this jar the problem persists.
Any help appreciated, thanks.

Probably one of your dependencies has a log4j dependency. You need to exclude it.
Try to look on the parent pom.

Does slf4j use commons-logging implementation by default?

I have only worked with log4j in the past. Now I am scouting a new project and noticing that it uses slf4j 1.7.2. I understand it is only an API specification which provides a simplified interface (AKA facade) to various implementations that conform to it, such as java.util.logging, log4j and logback. However, I noticed that commons-logging wasn't mentioned in the list on the API web site, however, its jar was in this app's classpath. When I removed it from the classpath to check whether it was the used implemetation, I confirmed that it indeed was:
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.
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
Is commons-logging indeed the default implementation for slf4j? Because their documentation says:
If no binding is found on the class path, then SLF4J will default to a no-operation implementation.
at the above linked page. And even though I have slf4j-nop-1.7.2.jar in the classpath, which I am guessing the default implementation referred to above is, I still get the exception asking for org/apache/commons/logging/LogFactory if the commons is not in the classpath, so I am confused.
A clarification would be appreciated.

You need a combination of the binding jar AND the logging implementation (JCL in this case) on the classpath.
Binding with a logging framework at deployment time
commons-logging is not the default, but if you have slf4j-jcl-1.7.2.jar on your classpath, it will try to use that. So if you therefore remove JCL from your path, it will complain that it can't find the classes.
slf4j-nop-1.7.2.jar is the no-op "SLF4J bindings" jar, not an implementation in itself.