Che succede con la registrazione in Java? [chiuso]

Perché uno dovrebbe usare uno dei seguenti pacchetti invece dell'altro?

• Registrazione Java
• Commons Logging
• log4j
• SLF4J
• logback

In ordine cronologico di apparenza api (per quanto ne so):

• Log4j perché quasi tutti lo usano (nella mia esperienza)
• Commons Logging perché i progetti open source lo utilizzano (in modo che possano integrarsi con qualsiasi framework di registrazione utilizzato nella soluzione integrata); particolarmente valido se sei un API / Framework / OSS e fai affidamento su altri pacchetti che utilizzano Commons Logging.
• Commons Logging perché non vuoi "bloccarti" a un particolare framework di registrazione (quindi invece ti limiti a ciò che Commons Logging ti dà invece) - Non penso che sia ragionevole decidere di utilizzare questo punto come motivo.
• Registrazione Java perché non vuoi aggiungere un jar extra.
• SLF4j perché è più recente di Commons Logging e fornisce la registrazione parametrizzata:

logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}

• Logback perché è più recente di log4j e, di nuovo, supporta la registrazione parametrizzata, poiché implementa direttamente SLF4j
• SLF4j / Logback perché è scritto dallo stesso tizio che ha fatto log4j, quindi lo ha migliorato (secondo Ken G - grazie. Sembra che si adatti quando si guardano i loro precedenti post di notizie )
• SLF4j perché pubblicano anche un adattatore log4j in modo da non dover "disattivare" log4j nel codice precedente - basta fare in modo che log4j.properties usi SLF4j e la sua configurazione

Trovo che il login in Java sia confuso, incoerente, scarsamente documentato e soprattutto casuale. Inoltre, c'è un'enorme quantità di somiglianza tra questi framework di registrazione che si traduce in una duplicazione degli sforzi e nella confusione sull'ambiente di registrazione in cui ci si trova effettivamente. In particolare, se si lavora in uno stack di applicazioni web Java serio, ci si trova spesso in multiploregistrazione di ambienti contemporaneamente; (es. hibernate può usare log4j e tomcat java.util.logging). Apache commons ha lo scopo di collegare diversi framework di registrazione, ma in realtà aggiunge solo più complessità. Se non lo sai prima del tempo, è assolutamente sconcertante. Perché i miei messaggi di registro non vengono stampati sulla console, ecc.? Ohh perché sto guardando i log di Tomcat e non log4j. Aggiungendo ancora un altro livello di complessità, il server delle applicazioni potrebbe avere configurazioni di registrazione globali che potrebbero non riconoscere le configurazioni locali per una particolare applicazione web. Infine, tutti questi framework di registrazione sono TROPPO COMPLICATI. L'accesso a Java è stato un pasticcio disorganizzato che ha lasciato gli sviluppatori come me frustrati e confusi.

Le prime versioni di Java non avevano un framework di registrazione integrato che portava a questo scenario.

C'è un punto importante che non è stato menzionato prima:

SLF4J (e sia Logback che LOG4J come backend di registrazione) supportano un cosiddetto Mapped Diagnostic Context (MDC, vedere javadoc e documentazione ).

Si tratta essenzialmente di una mappa <String, String> locale del thread che è possibile utilizzare per aggiungere ulteriori informazioni sul contesto all'evento di registrazione. Lo stato corrente dell'MDC è allegato a ogni evento.

Questo può essere incredibilmente utile se inserisci elementi come il nome utente e l'URL della richiesta (nel caso di una webapp). Questo può essere fatto automaticamente usando un filtro, per esempio.

Vedi anche le risposte alla domanda Quali sono le migliori pratiche per registrare un errore? , particolarmente:

• Esistono alcuni potenziali problemi di caricamento classi con Commons Logging.

• Log4J e SLF4J sono stati sviluppati dalla stessa persona, imparando dai problemi riscontrati nella pratica con Log4J.

Nel nostro progetto aziendale utilizziamo LOG4j ed è molto facile da usare come ha mostrato Stephen nel suo esempio. Abbiamo anche scritto le nostre classi di pattern per LOG4j in modo da poter creare i propri schemi di file di output. Puoi descrivere come dovrebbe apparire il tuo file di log. È possibile migliorare le classi log4j originali.

Tutte le proprietà LOG4j possono essere modificate in un file log4j.properties, in modo da poter utilizzare file diversi per progetti diversi.

La registrazione di Java non è la mia preferita, ma potrebbe essere perché utilizzo log4j dall'inizio.

La panoramica di Commons Logging fornisce il motivo della sua esistenza: la registrazione dal codice della libreria, quando non si ha alcun controllo sul framework di registrazione sottostante. Molto importante per i vari progetti Apache, che saranno collegati ad applicazioni esterne. Forse non così importante per i progetti IT interni, dove hai il controllo completo.

Detto questo, scrivo a Commons Logging, come fanno molti altri sviluppatori che conosco. Il motivo è ridurre al minimo il bagaglio mentale: puoi cambiare progetto o lavoro e non devi imparare un nuovo quadro (a condizione che il nuovo lavoro / progetto utilizzi anche CL, e / o puoi convincerli a passare ad esso).

Inoltre, c'è un certo valore nel creare i propri wrapper attorno a qualsiasi framework si utilizzi. Come descritto qui , mi piace usare un oggetto LogWrapper per fornire una stringa personalizzata (importante) e ridurre al minimo l'ingombro visivo delle istruzioni di registrazione (meno importante).

Generalmente userei per impostazione predefinita Log4J.

Userei Java Logging se non mi dispiacesse una dipendenza da Java 1.4, ma preferirei comunque Log4J.

Userei Commons Logging se stavo migliorando qualcosa che già lo usava.

Suggerirei di creare una sottile facciata di registrazione in grado di scrivere su qualsiasi framework di registrazione, a quel punto la scelta del motore di supporto diventa praticamente un punto controverso.