Prévenir Weblogic 12c de l'utilisation du système de slf4j de liaison

Nous construisons une nouvelle installation à l'aide de slf4j, comme l'exploitation forestière de la façade. Lors du déploiement sur les nouveaux Weblogic 12c, nous avons constaté cette erreur sur la console de log:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/Oracle/Middleware2/modules/org.slf4j.jdk14_1.6.1.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [zip:/opt/Oracle/Middleware2/user_projects/domains/m3/servers/AdminServer/tmp/_WL_user/test/t030q4/war/WEB-INF/lib/slf4j-log4j12-1.6.4.jar!/org/slf4j/impl/StaticLoggerBinder.class]

après googler, nous avons constaté que c'est juste un avertissement, slf4j va se lier d'abord trouvé enregistreur, qui dans ce cas est weblogic du système enregistreur de cadre. Est-il un moyen de le rendre lier à la journalisation dans notre fichier WAR? Avoir <préférez-web-inf-classes> dans weblogic.xml n'aide pas

OriginalL'auteur dhchen | 2012-03-16

  1. 29

    Le filtrage ne doit pas être fait sur les classes, mais sur les ressources, parce que SLF4J semble pour le StaticLoggerBinder.class comme une ressource et non comme une classe.

    De les inclure dans votre weblogic-application.xml ainsi:

    <wls:prefer-application-packages>
    <wls:package-name>org.slf4j.*</wls:package-name>
    <wls:package-name>org.apache.commons.*</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>

    et votre enregistreur sera utilisé à la place de l'un à l'intérieur du Système de chargeur de classe.

    Est le org.apache.communes.* entrée nécessaire pour faire SLF4J travail? Si oui, pourquoi?
    quelques jours de retard mais: com.apache.commons.l'exploitation forestière.*

    OriginalL'auteur Luca

  2. 4

    Pour la GUERRE de fichier, vous devez utiliser prefer-application-packages dans weblogic.xml comme décrit dans cette et cette postes.

    Dans votre cas, il sera quelque chose comme

    <?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" 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/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
    <wls:container-descriptor>
        <wls:prefer-application-packages>
            <wls:package-name>org.slf4j</wls:package-name>
        </wls:prefer-application-packages>
    </wls:container-descriptor>
</wls:weblogic-web-app>

    OriginalL'auteur fglez

  3. 3

    Nous avons également avoir ce problème et puisque nous sommes requises pour configurer la journalisation à l'aide de Log4J c'était un problème. Cependant, l'utilisation de prefer-application-packages semble fonctionner jusqu'à présent, c'est à dire mettre un weblogic-application.xml fichier dans le META-INF dossier de l'OREILLE avec les éléments suivants:

    <?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-application.xsd http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd" >
    <prefer-application-packages>
        <package-name>org.slf4j</package-name>
    </prefer-application-packages>
</weblogic-application>

    (ok spécifié xmlns est vieux, mais il fonctionne, vous pouvez le mettre à jour si vous voulez, j'ai juste pris la nôtre, et a supprimé les parties non liées).

    Nous avons encore le susmentionnés avertissement, mais il utilise Log4J que nécessaire. En fait, si vous regardez l'URL spécifiée sur la ligne suivante dans les journaux (omis ici dans la question), il est dit:

    L'avertissement émis par SLF4J est juste que, un avertissement. SLF4J va encore se lier avec le premier cadre, il trouve sur le chemin de classe.

    Donc je suppose qu'il utilise toujours la classe normale-mécanisme de chargement pour le chargement org.slf4j.impl.StaticLoggerBinder, dont nous avons réellement configuré de façon à préférer l'un à notre OREILLE (c'est à dire de faire la première sur le chemin de la classe).

    Encore, l'avertissement reste, mais il fonctionne. La fixation de l'avertissement serait bien, mais probablement pas possible sans altérer WebLogic la disposition de bibliothèques.

    OriginalL'auteur Didier L

  4. 0

    Je ne crois pas SLF4J fournit un moyen de forcer sa propre version, car il est basé sur la découverte de soi dans le classpath.

    Donc, si vous avez les droits d'administration sur WebLogic, la solution la plus simple est de mettre à jour le SLF4J version de WebLogic pour 1.6.4 en mettant à jour le fichier sur WebLogic dossier d'installation.

    Sinon, vous pouvez essayer de construire une OREILLE au lieu d'une GUERRE et de suivre les recommandations ici, bien que je doute que ce travail si préférez-web-inf-classes ne fonctionne pas dans une GUERRE.

    hein, ce que je veux dire, c'est "faire slf4j lier enregistreur de journal de la bibliothèque fournie par moi à la place de la liaison au système de bibliothèque". Ce n'est pas lié à slf4j version, depuis le passage à 1.6.1 cette erreur se produit, et selon slf4j du document, lorsque slf4j trouvé plusieurs bindable logger, c'est lier à la première enregistreur de frappe, qui est toujours du système slf44 de liaison

    OriginalL'auteur foch