log4j vs logback [chiuso]

Stiamo usando log4j dietro un wrapper fatto in casa. Abbiamo in programma di utilizzare molte più funzionalità ora.

Dovremmo aggiornare al logback?

(Intendo il quadro non una facciata come SLF4J)

Il logback implementa nativamente l'API SLF4J. Ciò significa che se si utilizza il logback, si sta effettivamente utilizzando l'API SLF4J. In teoria è possibile utilizzare direttamente gli interni dell'API di logback per la registrazione, ma ciò è altamente sconsigliato. Tutta la documentazione di log-back e gli esempi sui logger sono scritti in termini di API SLF4J.

Quindi, usando il logback, in realtà useresti SLF4J e se per qualsiasi motivo volessi tornare a log4j, potresti farlo in pochi minuti semplicemente facendo cadere slf4j-log4j12.jar sul tuo percorso di classe.

Quando si esegue la migrazione dal logback a log4j, le parti specifiche del logback, in particolare quelle contenute nel file di configurazione logback.xml , devono comunque essere migrate al suo equivalente log4j, ovvero log4j.properties . Quando si esegue la migrazione nell'altra direzione, la configurazione di log4j, ovvero log4j.properties , dovrebbe essere convertita nel suo equivalente di logback. C'è uno strumento online per quello. La quantità di lavoro necessaria per la migrazione dei file di configurazione è molto inferiore a quella necessaria per migrare le chiamate dei logger diffuse in tutto il codice sorgente del software e le sue dipendenze.

Dovresti? Sì .

Perché? Log4J è stato sostanzialmente deprecato da Logback .

È urgente? Forse no.

È indolore? Probabilmente, ma potrebbe dipendere dalle tue dichiarazioni di registrazione.

Si noti che se si desidera sfruttare appieno LogBack (o SLF4J), è necessario scrivere le istruzioni di registrazione appropriate . Ciò produrrà vantaggi come codice più veloce a causa della valutazione pigra e meno righe di codice perché è possibile evitare le protezioni.

Infine, consiglio vivamente SLF4J. (Perché ricreare la ruota con la tua facciata?)

Nel mondo del logging ci sono facciate (come Apache Commons Logging, slf4j o persino l'API Log4j 2.0) e implementazioni (Log4j 1 + 2, java.util.logging, TinyLog, Logback).

Fondamentalmente dovresti sostituire il tuo wrapper selfmade con slf4j IF e solo SE non sei soddisfatto per qualche motivo. Mentre Apache Commons Logging non fornisce realmente un'API moderna, slf4j e la nuova facciata Log4j 2 lo forniscono. Dato che un sacco di app usano slf4j come wrapper, potrebbe avere senso usarlo.

slf4j fornisce un certo numero di zucchero API, come questo esempio dai documenti slf4j:

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

È una sostituzione variabile. Questo è supportato anche da Log4j 2.

Tuttavia, è necessario essere consapevoli del fatto che slf4j è sviluppato da QOS che mantiene anche il logback. Log4j 2.0 è disponibile in Apache Software Foundation. Negli ultimi tre anni una comunità vivace e attiva è cresciuta di nuovo lì. Se apprezzi l'Open Source come viene fatto dalla Apache Software Foundation con tutte le sue garanzie, potresti riconsiderare l'utilizzo di slf4j in favore dell'utilizzo diretto di Log4j 2.

Notare che:

In passato log4j 1 non veniva mantenuto attivamente mentre Logback lo era. Ma oggi le cose sono diverse. Log4j 2 è attivamente gestito e viene rilasciato con una pianificazione quasi regolare. Include anche molte funzionalità moderne e -imho- rende un paio di cose migliori di Logback. A volte è solo una questione di gusti e dovresti trarre le tue conclusioni.

Ho scritto una rapida panoramica delle nuove funzionalità di Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html

Durante la lettura vedrai che Log4j 2 è stato ispirato da Logback ma anche da altri framework di registrazione. Ma la base di codice è diversa; non condivide quasi nulla con Log4j 1 e zero con Logback. Ciò ha portato ad alcuni miglioramenti come nell'esempio Log4j 2 funziona con bytestreams invece che con Stringhe sotto il cofano. Inoltre non perde eventi durante la riconfigurazione.

Log4j 2 può accedere con una velocità superiore rispetto ad altri framework che conosco: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html

Eppure la comunità di utenti sembra essere molto più grande di Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html

Detto questo, l'idea migliore è scegliere i framework di registrazione che si adattano meglio a ciò che si desidera ottenere. Non cambierei un framework completo se disabilitassi la registrazione nell'ambiente di produzione ed eseguissi semplicemente la registrazione di base nella mia app. Tuttavia, se si fa un po 'di più con la registrazione, basta guardare le funzionalità fornite dai framework e dai loro sviluppatori. Mentre ricevi supporto commerciale per Logback tramite QOS (ho sentito) non esiste attualmente alcun supporto commerciale per Log4j 2. D'altra parte, se hai bisogno di fare la registrazione di controllo e hai bisogno di prestazioni elevate fornite dagli appendici asincrone, ha molto senso controlla log4j 2.

Si noti che nonostante tutto il comfort che offrono, le facciate mangiano sempre una piccola prestazione. Forse non ti sta affatto influenzando, ma se hai poche risorse potresti dover salvare tutto ciò che puoi avere.

Senza conoscere meglio le tue esigenze è quasi impossibile dare una raccomandazione. Solo: non cambiare solo perché molte persone cambiano. Passa solo perché ne vedi il valore. E l'argomento secondo cui log4j è morto non conta più. È vivo e fa caldo.

NOTA BENE: Attualmente sono VP, Apache Logging Services e sono coinvolto anche in log4j.

Non rispondendo esattamente alla tua domanda, ma se potessi allontanarti dal tuo wrapper fatto da te, allora c'è Simple Logging Facade for Java (SLF4J) a cui Hibernate è ora passato (invece della registrazione comune).

SLF4J non presenta nessuno dei problemi del caricatore di classe o perdite di memoria osservate con Jakarta Commons Logging (JCL).

SLF4J supporta la registrazione JDK, log4j e il logback. Quindi, dovrebbe essere abbastanza facile passare da log4j al logback quando è il momento giusto.

Modifica: Aplogie che non mi ero chiarito. Stavo suggerendo di usare SLF4J per isolarti dal dover fare una scelta difficile tra log4j o logback.

La tua decisione dovrebbe essere basata su

• il tuo reale bisogno di queste "più funzionalità"; e
• il costo previsto per l'implementazione della modifica.

Dovresti resistere alla tentazione di cambiare API solo perché è "più nuovo, più lucido, migliore". Seguo una politica di "se non è rotto, non calciarlo".

Se l'applicazione richiede un framework di registrazione molto sofisticato, è possibile considerare il perché.

Il progetto maturo o persino il progetto in profondità nelle fasi di sviluppo probabilmente perderebbe più di un guadagno da tale aggiornamento, IMHO. Il logback è sicuramente molto più avanzato in una serie di punti, ma non in misura per la completa sostituzione in un sistema funzionante. Considererei sicuramente il logback per un nuovo sviluppo, ma log4j esistente è abbastanza buono e maturo per tutto ciò che è già stato rilasciato e incontrato l'utente finale. Questo è molto soggettivo, dovresti vedere costare te stesso.