Comment configurer la journalisation dans Hibernate 4?

Question

Hibernate 3.x slf4j pour la journalisation. Hibernate 4.x utilise jboss enregistrement. Je suis en train d'écrire une application autonome qui utilise Hibernate 4, et SLF4J pour la journalisation.

Comment puis-je configurer Hibernate pour vous connecter à SLF4J?

Si ce n'est pas possible, comment puis-je configurer Hibernate sur l'exploitation forestière?

L'Hibernation du manuel de l'article concernant l'enregistrement commence avec l'avertissement que c'est ...

Complètement obsolète. Hibernate utilise JBoss Journalisation partir de la version 4.0. Cela permet d'obtenir des documentée que nous transférer ce contenu pour le Guide du Développeur.

... continue à parler de SLF4J, et est donc inutile. Ni le guide de mise en route , ni le guide du développeur de parler de l'exploitation forestière à tous. De même, le guide de migration.

J'ai cherché de la documentation sur jboss enregistrement lui-même, mais je n'ai pas été capable de trouver n'importe à tous. La page GitHub est silencieux, et JBoss de projets communautaires page n'a même pas de liste de jboss-exploitation forestière. Je me demandais si le th du projet de bug tracker peut-être des questions relatives à la fourniture de la documentation, mais il ne le fait pas.

La bonne nouvelle, c'est que lors de l'utilisation d'Hibernate 4 à l'intérieur d'un serveur d'application, tels que JBoss AS7, l'exploitation forestière est en grande partie pris en charge pour vous. Mais comment puis-je configurer dans une application autonome?

Answer 1

Regarder https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/LoggerProviders.java:

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();
}

Donc les valeurs possibles pour org.jboss.logging.provider sont: jboss, jdk, log4j, slf4j.

Si vous ne définissez pas d' org.jboss.logging.provider il essaie de jboss, puis log4j, puis slf4j (seulement si logback utilisé) et un repli vers le jdk.

J'utilise slf4j avec logback-classic:

    <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.0.13</version>
        <scope>${logging.scope}</scope>
    </dependency>

et tous les beaux travaux!

Answer 2

Pour obtenir SLF4J de travailler avec JBoss abattage sans Logback comme backend nécessite l'utilisation d'un système de propriété org.jboss.logging.provider=slf4j. log4j-over-slf4j tactiques ne semble pas fonctionner dans ce cas parce que l'enregistrement va retomber JDK si ni Logback, ni log4j n'est pas réellement présent dans le classpath.

C'est un peu une nuisance, et pour obtenir la détection automatique fonctionne, vous devez voir que le chargeur de classe contient au moins ch.qos.logback.classic.Logger de logback-classique ou org.apache.log4j.Hierarchy de log4j pour le truc de l'JBoss Journalisation de ne pas retomber à la journalisation JDK.

La magie est interprété org.jboss.logging.LoggerProviders

Mise à JOUR: le Service, chargeur de soutien a été ajouté, de sorte qu'il est possible d'éviter des problèmes avec la détection automatique en déclarant META-INF/services/org.jboss.logging.LoggerProvider (avec org.jboss.logging.Slf4jLoggerProvider comme valeur). Il semble y avoir ajouté le support log4j2.

Answer 3

Inspiré par Leif Hypoport post, c'est la façon dont je "plié" Hibernate 4 retour à la slf4j:

Supposons que vous êtes à l'aide de Maven.

• Ajouter org.slf4j:log4j-over-slf4j comme une dépendance à votre pom.xml
• À l'aide de la commande mvn dependency:tree, assurez-vous que aucun des objets que vous utilisez depende sur slf4j:slf4j (pour être précis, aucun artefact doit avoir une compilation de la portée de la dépendance ou de l' exécution de la portée de la dépendance sur slf4j:slf4j)

Contexte: Hibernate 4.x a une dépendance sur l'artefact org.jboss.logging:jboss-logging. Transitivement, cet artefact a une condition de la portée de la dépendance sur l'artefact slf4j:slf4j.

Maintenant que nous avons ajouté l' org.slf4j:log4j-over-slf4j artefact, org.slf4j:log4j-over-slf4j mimicks l' slf4j:slf4j artefact. Donc tout ce qui JBoss Logging journaux va maintenant passer par slf4j.

Disons que vous êtes à l'aide de Logback que votre enregistrement backend. Voici un exemple d' 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>

Sur votre chemin de classe, ont un logback.xml, comme celui-ci, situé en 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 -->

Certains composants peuvent souhaitez avoir accès à l' logback.xml à la JVM de temps pour une bonne journalisation, par exemple, le Plugin Maven Jetty. Dans ce cas, ajouter un système Java logback.configurationFile=./path/to/logback.xml sur votre commande (par exemple, mvn -Dlogback.configurationFile=./target/classes/logback.xml jetty:run).

Dans le cas où vous êtes encore en train de "raw" de la console stdout Hibernate sortie (comme Hibernate: select ...), puis de Débordement de Pile question "désactiver la veille prolongée de journalisation de la console " peut s'appliquer.

Answer 4

Tout d’abord, vous réalisez que SLF4J n’est pas un droit de bibliothèque de journalisation, mais un wrapper de journalisation. Il ne se connecte rien en soi, il délègue simplement à "backends".

Pour "configurer" jboss-logging, vous devez simplement ajouter le framework de journal que vous souhaitez utiliser sur votre chemin de classe (avec jboss-logging) et jboss-logging calcule le reste.

Answer 5

J'utilise Hibernate Core 4.1.7.Final plus Spring 3.1.2.RELEASE dans une application autonome. J'ai ajouté Log4j 1.2.17 à mes dépendances et il semble que JBoss Logging se connecte directement à log4j si disponible et que Spring utilise Commons Logging, qui utilise également Log4j si disponible, toute la journalisation peut être configurée via Log4J.

Voici ma liste de dépendances pertinentes:

 <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>