logger Log4j per classe vs logger per applicazione

5

Sono bloccato nel comprendere un concetto correlato alla creazione di Logger, specialmente nel contesto di Java EE.

Nella mia esperienza, ho quasi sempre utilizzato un logger per applicazione, con pochi casi in cui avevo bisogno di un logger specifico per una parte specifica dell'applicazione. Solo in questi casi stavo creando attraverso il mio wrapper un nuovo logger. E, se parliamo di identificare la classe che ha chiamato il logger, stavo facendo una cosa semplice:

public const String ThisIdentifier = "MyLoggerCallingClass";

E stavo passando questo come parametro al metodo logger, anche se c'erano alcune sequenze di tasti aggiuntive che dovevo fare.

Ora mi trovo di fronte a un problema concettuale: Perché creare logger per classe e non uno per applicazione.
Ho trovato le risposte seguenti:

Il modo migliore per inizializzare i logger

Perché i logger per classe raccomandano

Tuttavia, se ottengo queste informazioni da documentazione apache su getLogger :

Retrieve a logger named according to the value of the name parameter. If the named logger already exists, then the existing instance will be returned. Otherwise, a new instance is created.

Capisco che se faccio il modo per classe, e diciamo che ho 50 pacchetti in un'applicazione Java EE, e 10 classi per pacchetto, avrò 500 istanze logger nella mia app!

Vengo da una prospettiva C, C ++ e C #, e sempre nella mia mente ho il seguente:
"Usa la memoria con parsimonia, crea istanze solo se necessario, ripulisci te stesso, non abusare ecc ..."

Non conosco i dettagli effettivi della creazione del logger e capisco l'idea di poter filtrare meglio i risultati del log, ma qualcuno può spiegarmi perché andare in quel modo e quanto sia utile alla fine, per creare un'istanza per classe, perché sprecare memoria e avere molte istanze, invece di chiamare semplicemente un metodo logger con un parametro?

Modifica

Anche se è vero, che in generale le persone non si preoccupano delle molte cosiddette istanze di logger "leggere" create, ho finito con i miei colleghi sul progetto per creare una classe wrapper per log4j, che ho istanza in ogni classe dove voglio usare il logger. Questa classe wrapper contiene un riferimento a una singola istanza di logger di default

Logger.getLogger(Wrapperclass.getName())

e anche il nome della classe in cui viene chiamato questo logger specifico, quindi per registrare il nome della classe di registrazione. Nel caso in cui avrò bisogno di classi specifiche da registrare, cambierò semplicemente

Logger.getLogger(Wrapperclass.getName())

a

Logger.getLogger(Callingclass.getName())

ricostruisci l'app ed eseguila. Secondo me questa soluzione sembra più pulita e ordinata.

EDIT 2:

Ho trovato questo :

Based on our previous work on log4j, logback internals have been re-written to perform about ten times faster on certain critical execution paths. Not only are logback components faster, they have a smaller memory footprint as well

Sulla base della citazione di cui sopra, in cui possiamo chiaramente vedere la frase contenente "impronta di memoria più piccola", posso concludere che i miei sospetti non erano così falsi. Con il team ora prendiamo in considerazione l'idea di passare al logback se saremo in grado di ottenere la stessa funzionalità di registrazione che abbiamo bisogno e facciamo con log4j.

Spero che questa domanda aiuti gli altri a prendere la decisione giusta!

    
posta XMight 25.02.2016 - 11:00
fonte

1 risposta

4

Sembra esserci una discrepanza tra ciò che intendi con la parola "logger" e ciò che il framework Log4J intende con "logger".

All'interno del framework Log4J, un logger è una classe molto snella. Non è molto più di un wrapper attorno al ThisIdentifier che si utilizza e un contenitore per funzioni che generano istruzioni di registrazione.
Tutto il pesante sollevamento della registrazione avviene in Appendici, Filtri e Layout.

Come indicato nell'architettura Log4J

Logger

As stated previously, Loggers are created by calling LogManager.getLogger. The Logger itself performs no direct actions. It simply has a name and is associated with a LoggerConfig. It extends AbstractLogger and implements the required methods. As the configuration is modified Loggers may become associated with a different LoggerConfig, thus causing their behavior to be modified.

Quindi, avere diverse centinaia di% di istanze diLogger non pone alcun onere di conseguenze sul tuo sistema.

    
risposta data 25.02.2016 - 11:31
fonte

Leggi altre domande sui tag