Les nouveaux projets doivent-ils utiliser logback au lieu de log4j ?

Question

Les nouveaux projets devraient-ils utiliser logback au lieu de log4j comme cadre de journalisation ?

Ou avec d'autres mots : 'Est-ce que logback est meilleur que log4j (en laissant de côté la 'caractéristique' SLF4J de logback) ?

Answer 1

Vous devez utiliser SLF4J+Logback pour la journalisation.

Il offre des fonctionnalités intéressantes comme les messages paramétrés et (contrairement à commons-logging) un contexte de diagnostic mappé (MDC), javadoc , documentation ).

L'utilisation de SLF4J rend le backend de journalisation échangeable d'une manière assez élégante.

En outre, SLF4J supporte le pontage d'autres cadres de journalisation à l'implémentation SLF4J que vous utiliserez afin que les événements de journalisation provenant de logiciels tiers apparaissent dans vos journaux unifiés - à l'exception de java.util.logging qui ne peut pas être relié de la même manière que les autres cadres de journalisation.

Le pontage de jul est expliqué dans le javadocs de SLF4JBridgeHandler.

J'ai eu une très bonne expérience en utilisant la combinaison SLF4J+Logback dans plusieurs projets et le développement de LOG4J s'est pratiquement arrêté.

Le SLF4J présente encore les inconvénients suivants :

• Il ne supporte pas les varargs pour rester compatible avec Java < 1.5
• Il ne permet pas d'utiliser simultanément un message paramétré et une exception.
• Il ne contient pas de support pour un contexte de diagnostic imbriqué (NDC), javadoc ) que le LOG4J possède.

Answer 2

L'auteur (à la fois de Logback et de Log4j) propose une liste de raisons de changer à l'adresse suivante http://logback.qos.ch/reasonsToSwitch.html .

En voici quelques-uns qui ont retenu mon attention ;

• Une mise en œuvre plus rapide

  Basé sur notre travail précédent sur log4j, internes de logback ont été réécrits pour être environ dix fois plus rapides plus rapide sur certains chemins d'exécution d'exécution critiques. Non seulement les composants de logback plus rapides, ils ont également une mais aussi une plus petite empreinte mémoire.

• Rechargement automatique des fichiers de configuration

  Logback-classic peut automatiquement recharger son fichier de configuration lors de modification. Le processus d'analyse est rapide et sûr car il n'implique pas la car il n'implique pas la création d'un distinct pour l'analyse. Cette subtilité technique technique permet à logback de fonctionner bien au sein des serveurs d'applications et et plus généralement dans l'environnement JEE et plus généralement dans l'environnement JEE.

• Traces de piles avec données d'emballage

  Lorsque logback imprime une exception, la trace de la pile comprendra les données données. Voici un exemple de trace de pile généré par l'application web logback-demo l'application web.

  14:28:48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction - 99 n'est pas une n'est pas une valeur valide java.lang.Exception : 99 n'est pas valide
  at ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/:na] at org.apache.struts.action.RequestProcessor.processeur.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9] at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar:1.2.9] at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12]
  sur org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12] à ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/:na] à org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12] à org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12] à org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar:6.1.12] à org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]

  A partir de ce qui précède, vous pouvez reconnaître que l'application utilise Struts version 1.2.9 et a été déployée sous jetty version 6.1.12. Ainsi, les traces traces informeront rapidement le lecteur sur les classes impliquées dans l'exception exception mais aussi le paquet et les versions de package auxquelles elles appartiennent. Lorsque vos clients vous envoient une trace trace, en tant que développeur, vous n'aurez plus besoin de leur demander de vous envoyer informations sur les versions des paquets qu'ils utilisent. L'adresse informations feront partie de la pile trace. Voir le mot de conversion "%xThrowable pour plus de détails.

  Cette fonction peut être très utile au point que au point que certains utilisateurs la considèrent considérer comme une fonctionnalité de leur IDE.

• Suppression automatique des anciennes archives de journaux

  En définissant la propriété maxHistory de TimeBasedRollingPolicy ou de SizeAndTimeBasedFNATP, vous pouvez contrôler le nombre maximum de fichiers archivés. Si votre politique de roulement politique de roulement prévoit un roulement mensuel et et que vous souhaitez conserver un an d'archives journaux, il suffit de définir la propriété maxHistory à 12. Les fichiers journaux archivés de plus de 12 mois seront automatiquement supprimés.

Il peut y avoir un parti pris, mais c'est le même homme qui a écrit les deux frameworks et s'il dit d'utiliser Logback plutôt que Log4j, il vaut probablement la peine de l'écouter.

Answer 3

J'utiliserais slf4j pour la journalisation dans tous les cas. Cela vous permet de choisir le backend de journalisation que vous voulez utiliser, au moment du déploiement plutôt qu'au moment du codage.

Cela s'est avéré très précieux pour moi. Il me permet d'utiliser log4j dans les anciennes JVM, et logback dans les JVM 1.5+, ainsi que java.util.logging si nécessaire.

Answer 4

Logback est plus sensible à Java EE :
en général (du code à la documentation), il faut garder à l'esprit les conteneurs - comment coexistent plusieurs applications, comment les chargeurs de classe sont mis en œuvre, etc. Contextes pour les loggers, JNDI, configuration JMX incluse etc.

Du point de vue du développeur, Logback est presque identique, mais il ajoute Une journalisation paramétrée (il n'est pas nécessaire d'utiliser if(logger.isDebugEnabled()) pour éviter les surcharges de concaténation de chaînes).

Log4j - le seul gros avantage est le support des anciennes JVM, petit (IMO) NDC (Logback seulement MDC), quelques extensions. Par exemple, j'ai écrit une extension pour configureAndWatch pour Log4j, mais pas pour Logback.

Answer 5

Le log4j original et le logback ont été conçus et implémentés par le même gars.

plusieurs outils open source ont utilisé SLF4J. Je ne vois pas de déficiences importantes dans cet outil. Donc, à moins que vous n'ayez beaucoup d'extensions de log4j dans votre codebase, j'irais de l'avant avec logback.