Hibernate 3.x used slf4j for logging. Hibernate 4.x uses jboss-logging. I am writing a standalone application which uses Hibernate 4, and SLF4J for logging.
How can i configure Hibernate to log to SLF4J?
If that's not possible, how can i configure Hibernate's logging at all?
The Hibernate 4.1 manual section on logging starts with the warning that it is ...
Completely out of date. Hibernate uses JBoss Logging starting in 4.0. This will get documented as we migrate this content to the Developer Guide.
... goes on to talk about SLF4J, and so is useless. Neither the getting started guide nor the developer guide talk about logging at all. Nor does the migration guide.
I have looked for documentation on jboss-logging itself, but i haven't been able to find any at all. The GitHub page is silent, and JBoss's community projects page doesn't even list jboss-logging. I wondered if th project's bug tracker might have any issues relating to providing documentation, but it doesn't.
The good news is that when using Hibernate 4 inside an application server, such as JBoss AS7, logging is largely taken care of for you. But how can i configure it in a standalone application?
static final String LOGGING_PROVIDER_KEY = "org.jboss.logging.provider";
private static LoggerProvider findProvider() {
// Since the impl classes refer to the back-end frameworks directly, if this classloader can't find the target
// log classes, then it doesn't really matter if they're possibly available from the TCCL because we won't be
// able to find it anyway
final ClassLoader cl = LoggerProviders.class.getClassLoader();
try {
// Check the system property
final String loggerProvider = AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
return System.getProperty(LOGGING_PROVIDER_KEY);
}
});
if (loggerProvider != null) {
if ("jboss".equalsIgnoreCase(loggerProvider)) {
return tryJBossLogManager(cl);
} else if ("jdk".equalsIgnoreCase(loggerProvider)) {
return tryJDK();
} else if ("log4j".equalsIgnoreCase(loggerProvider)) {
return tryLog4j(cl);
} else if ("slf4j".equalsIgnoreCase(loggerProvider)) {
return trySlf4j();
}
}
} catch (Throwable t) {
}
try {
return tryJBossLogManager(cl);
} catch (Throwable t) {
// nope...
}
try {
return tryLog4j(cl);
} catch (Throwable t) {
// nope...
}
try {
// only use slf4j if Logback is in use
Class.forName("ch.qos.logback.classic.Logger", false, cl);
return trySlf4j();
} catch (Throwable t) {
// nope...
}
return tryJDK();
}
So possible values for org.jboss.logging.provider are: jboss, jdk, log4j, slf4j.
If you don't set org.jboss.logging.provider it tries jboss, then log4j, then slf4j (only if logback used) and fallback to jdk.
I use slf4j with logback-classic:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.13</version>
<scope>${logging.scope}</scope>
</dependency>
and all work fine!
UPDATE Some users uses in very main App.java:
static { //runs when the main class is loaded.
System.setProperty("org.jboss.logging.provider", "slf4j");
}
but for container based solutions this is not worked.
UPDATE 2 Those who think that they manage Log4j with SLF4J for jboss-logging it is not exactly thus. jboss-logging directly uses Log4j without SLF4J!
To get SLF4J to work with JBoss Logging without Logback as backend requires usage of a system property org.jboss.logging.provider=slf4j. log4j-over-slf4j tactics doesn't seem to be working in this case because the logging will fall back to JDK if neither Logback nor log4j isn't actually present in classpath.
This is a bit of a nuisance and in order to get autodetection to work you have see that the classloader contains at least ch.qos.logback.classic.Logger from logback-classic or org.apache.log4j.Hierarchy from log4j to trick the JBoss Logging from not falling back to JDK logging.
The magic is interpreted at org.jboss.logging.LoggerProviders
UPDATE: Service loader support has been added so it is possible to avoid problems with autodetection by declaring META-INF/services/org.jboss.logging.LoggerProvider (with org.jboss.logging.Slf4jLoggerProvider as a value). There seems to be added support log4j2 as well.
Inspired by Leif's Hypoport post, this is how I "bent" Hibernate 4 back to slf4j:
Let's assume you are using Maven.
- Add
org.slf4j:log4j-over-slf4jas a dependency to yourpom.xml - Using the command
mvn dependency:tree, make sure none of the artifacts you're using depende onslf4j:slf4j(to be precise, no artifact shall have a compile scope dependency or runtime scope dependency onslf4j:slf4j)
Background: Hibernate 4.x has a dependency on the artifact org.jboss.logging:jboss-logging. Transitively, this artifact has a provided scope dependency on the artifact slf4j:slf4j.
As we now have added the org.slf4j:log4j-over-slf4j artifact, org.slf4j:log4j-over-slf4j mimicks the slf4j:slf4j artifact. Therefore everything that JBoss Logging logs will now actually go via slf4j.
Let's say you're using Logback as your logging backend. Here is a sample pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
....
<properties>
....
<slf4j-api-version>1.7.2</slf4j-api-version>
<log4j-over-slf4j-version>1.7.2</log4j-over-slf4j-version>
<jcl-over-slf4j-version>1.7.2</jcl-over-slf4j-version> <!-- no problem to have yet another slf4j bridge -->
<logback-core-version>1.0.7</logback-core-version>
<logback-classic-version>1.0.7</logback-classic-version>
<hibernate-entitymanager-version>4.1.7.Final</hibernate-entitymanager-version> <!-- our logging problem child -->
</properties>
<dependencies>
<!-- begin: logging-related artifacts .... -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j-api-version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${jcl-over-slf4j-version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>${log4j-over-slf4j-version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback-core-version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback-classic-version}</version>
</dependency>
<!-- end: logging-related artifacts .... -->
<!-- begin: some artifact with direct dependency on log4j:log4j .... -->
<dependency>
<groupId>org.foo</groupId>
<artifactId>some-artifact-with-compile-or-runtime-scope-dependency-on-log4j:log4j</artifactId>
<version>${bla}</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- begin: some artifact with direct dependency on log4j:log4j .... -->
<!-- begin: a hibernate 4.x problem child........... -->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>${hibernate-entitymanager-version}</version>
</dependencies>
<!-- end: a hibernate 4.x problem child........... -->
....
</project>
On your classpath, have a logback.xml, such as this one located in src/main/java:
<!-- begin: logback.xml -->
<configuration>
<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<logger name="org.hibernate" level="debug"/>
<root level="info">
<appender-ref ref="console"/>
</root>
</configuration>
<!-- end: logback.xml -->
Some components may want to have access to logback.xml at JVM start-up time for proper logging, for instance the Jetty Maven Plugin. In that case, add a Java system logback.configurationFile=./path/to/logback.xml to your command (e.g. mvn -Dlogback.configurationFile=./target/classes/logback.xml jetty:run).
In case you are still getting "raw" console stdout Hibernate output (like Hibernate: select ...), then Stack Overflow question " Turn off hibernate logging to console " may apply.
First you do realize that SLF4J is not a logging library right, its a logging wrapper. It itself does not log anything, it simply delegates to "backends".
To "configure" jboss-logging you just add whatever log framework you want to use on your classpath (along with jboss-logging) and jboss-logging figures out the rest.
I created a Hibernate-focused guide to JBoss Logging config: http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html
I'm using Hibernate Core 4.1.7.Final plus Spring 3.1.2.RELEASE in a standalone app. I added Log4j 1.2.17 to my dependencies and it seems, as JBoss Logging logs directly to log4j if available and Spring uses Commons Logging, witch also uses Log4j if available, all Logging could be configured via Log4J.
Here's my list of relevant dependencies:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.1.7.Final</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.1.2.RELEASE</version>
</dependency>
Hibernate 4.3 has some documentation about how to control org.jboss.logging:
It searches the class-path for a logging provider. It searches for slf4j after searching for log4j. So, in theory, ensuring that your classpath (WAR) does not include log4j and does include the slf4j API and a back-end should work.
As a last resort you can set the
org.jboss.logging.providersystem property toslf4j.
Despite the claims of the documentation, org.jboss.logging insisted on trying to use log4j, despite log4j being absent and SLF4J being present, resulting in the following message in my Tomcat log file (/var/log/tomcat/catalina.out):
log4j:WARN No appenders could be found for logger (org.jboss.logging).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
I had to follow the suggestion of the answer by dasAnderl ausMinga and include the log4j-over-slf4j bridge.
I use maven and added the following dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.6.6</version>
</dependency>
Then, I created a log4j.properties files in /src/main/resources:
# direct log messages to stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
# set log levels
log4j.rootLogger=warn
This will put it at the root of your .jar. It works like a charm...
so, just got it working in my project. hibernate 4, slf4j, logback. my project is gradle, but should be same for maven.
Basically Abdull is right. Where he is NOT right, is that you DONT have to remove slf4j from dependencies.
include to compile scope:
org.slf4j:slf4j-api
org.slf4j:log4j-over-slf4j
e.g. for logback (ch.qos.logback:logback-classic, ch.qos.logback:logback-core:1.0.12)
completely exclude log4j libs from dependencies
result: hibernate logs via slf4j to logback. of course you should be able to use different log implementation than logback
to be sure that no log4j is present, check your libs on classpath or web-inf/lib for war files.
of course you have set the loggers in logback.xml e.g. :
<logger name="org.hibernate.SQL" level="TRACE"/>
I had an issue making hibernate 4 logging work with weblogic 12c and log4j. The solution is to put the following in your weblogic-application.xml:
<prefer-application-packages>
<package-name>org.apache.log4j.*</package-name>
<package-name>org.jboss.logging.*</package-name>
</prefer-application-packages>
To anyone that could face the same problem I had. In case you have tried all the other solutions explained here and still don't see hibernate logging working with your slf4j, it could be because you are using a container that has in his folder libraries the jboss-logging.jar. This means that gets preloaded before you can even set any configuration to influence it. To avoid this problem in weblogic you can specify in the file weblogic-application.xml in you ear/META-INF to prefer the library loaded from the application. there should be a similar mechanism for other server containers. In my case I had to add:
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_5.xsd http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.5/weblogic-application.xsd">
<wls:prefer-application-packages>
<!-- logging -->
<wls:package-name>org.slf4j.*</wls:package-name>
<wls:package-name>org.jboss.logging.*</wls:package-name>
</wls:prefer-application-packages>
<wls:prefer-application-resources>
<wls:resource-name>org/slf4j/impl/StaticLoggerBinder.class</wls:resource-name>
</wls:prefer-application-resources>
</wls:weblogic-application>
did you try this:
- slf4j-log4j12.jar in the case of Log4J. See the SLF4J documentation for more detail. To use Log4j you will also need to place a log4j.properties file in your classpath. An example properties file is distributed with Hibernate in the src/ directory
just add these jars and properties or log4j xml in the classpath
来源：https://stackoverflow.com/questions/11639997/how-do-you-configure-logging-in-hibernate-4-to-use-slf4j