2012-07-11 25 views
21

Esiste comunque la possibilità di forzare slf4j a utilizzare un provider di registrazione specifico (logback nel mio caso)? Come nei loro documenti:Forza slf4j per utilizzare il logback

più associazioni sono state trovate sul percorso della classe

SLF4J API è desinged di legarsi con uno e un solo quadro di registrazione sottostante alla volta. Se è presente più di un'associazione sul percorso della classe, SLF4J emetterà un avviso, elencando la posizione di tali collegamenti. Quando sono disponibili più collegamenti sul percorso della classe, selezionare uno e solo un legame che si desidera utilizzare e rimuovere gli altri collegamenti. Ad esempio, se si ha sia slf4j-> simple-1.6.6.jar e slf4j-nop-1.6.6.jar sul percorso classe e si desidera utilizzare il bind nop (> no-operation), quindi rimuovere slf4j- simple-1.6.6.jar dal percorso della classe. Se non è possibile rimuovere i binding superflui, SLF4J si legherà ancora con un framework/implementazione di logging. A partire dalla versione 1.6.6, SLF4J assegnerà un nome alla classe framework/implementazione a cui è effettivamente associato.

NOTA L'avviso emesso da SLF4J è proprio questo, un avvertimento.

Nel mio caso ho log4j.jar, slf4j-log4j12.jar, log4j-over-slf4j.jar e tutti i vasi logback in classpath. So che è un errore avere slf4j-log4j12.jar e log4j-over-slf4j.jar insieme, ma il mio progetto è molto grande, e non è sempre semplice trovare ed escludere la dipendenza da esperti. In questo caso slf4j non ha nemmeno stampato alcun avvertimento, perché usiamo solo le configurazioni di logback. Mi ci è voluto un giorno per capire questo baratro dell'inferno.

Tutto quello che voglio è forzare slf4j utilizzare il logback tramite argomento JVM, ad esempio, in modo che possa stampare avvisi e posso escludere barattoli in futuro.

risposta

14

Altro che pulire il percorso della classe, non c'è modo di forzare SLF4J a collegarsi con una determinata implementazione.

+0

E 'un peccato per me – madhead

17

Generalmente il proprio codice si trova all'inizio del classpath. A causa di questo, un modo per farlo è quello di creare la propria classe org.slf4j.impl.StaticLoggerBinder:

package org.slf4j.impl; 

import org.slf4j.ILoggerFactory; 
import org.slf4j.spi.LoggerFactoryBinder; 

/** 
* Force tests to use JDK14 for logging. 
*/ 
@SuppressWarnings("UnusedDeclaration") 
public class StaticLoggerBinder implements LoggerFactoryBinder { 
    private static final StaticLoggerBinder SINGLETON = new StaticLoggerBinder(); 

    public static String REQUESTED_API_VERSION = "1.6"; 

    public static final StaticLoggerBinder getSingleton() { 
     return SINGLETON; 
    } 

    private StaticLoggerBinder() { 
    } 

    @Override 
    public ILoggerFactory getLoggerFactory() { 
     return new JDK14LoggerFactory(); 
    } 

    @Override 
    public String getLoggerFactoryClassStr() { 
     return "org.slf4j.impl.JDK14LoggerFactory"; 
    } 
} 
+0

Grazie per la risposta, ma ho già ripulito il mio percorso di classe . – madhead

+2

Anche questa è un'ottima risposta – StormeHawke

+0

come utilizzare questo codice per il logback, cosa dovrebbe restituire ILoggerFactory getLoggerFactory() invece del nuovo JDK14LoggerFactory() – nagSumanth