C'est le schéma classique, probablement celui qui est utilisé dans le code et par le plus grand nombre de librairies qui datent un peu. L'idée ici est d'exclure la librairie commons-logging partout où elle est référencée dans le projet, afin de la remplacer par jcl-over-slf4j qui basiquement fournit les mêmes classes et packages, mais redirige les logs vers SLF4J. Pour ce faire on pourra suivre par exemple la démarche suivante:

• s'il s'agit d'un projet maven multi-module, éditer en priorité le pom parent. Sinon éditer le fichier pom.xml du projet et aller à la section correspondant au dependencyManagement, qui permet, rappelons le, de déclarer un comportement commun pour toutes les librairies qui y sont référencées, indépendamment d'où elles sont par la suite utilisées dans le projet.
• recenser ensuite toutes les librairies du projet qui dépendent de commons-logging directement ou par transitivité, et s'assurer qu'elles soient bien déclarées dans la section dependencyManagement (attention cela ne remplace pas une déclaration dans la section "dependencies" du pom, mais ça permet de n'y déclarer pour chaque artefact que son id et son group-id, le reste étant configuré une fois pour toutes dans le dependencyManagement)
• Pour toutes les librairies recensées à l'étape précédente, exclure du dependencyManagement les dépendances vers commons-logging (et commons-logging-api s'il y a lieu)

Ca peut déjà être le cas pour certaines dépendances. En théorie il est possible que la librairie slf4j-log4j12 (ou logback) soit présente dans le projet, permettant de rediriger ces logs vers log4j. Sinon ils sont perdus. Pour ce cas de figure il n'y a pas grand chose à faire, simplement s'assurer que la librairie slf4j-log4j12 soit bien présente dans les dépendances par défaut du projet.

Comme le but à ce stade est d'utiliser SLF4J comme API de logging, mais de continuer de s'appuyer sur log4J pour le framework de logging, on va laisser les choses comme ça pour le moment. Lorsqu'on basculera sur lobgback, on remplacera log4j par l'adaptateur log4j-over-slf4j, mais comme ce dernier surcharge les classes de log4j, si on le fait dés maintenant il va y avoir un conflit entre les deux librairies.

Ce cas est le plus épineux. En effet jul-to-slf4j ne peut pas faire comme les autres adaptateurs (jcl-over-slf4j et log4j-over-slf4j), qui réimplémentent les classes des librairies qu'ils remplacent (respectivement commons-logging et log4j), car les packages correspondant du JDK sont protégés et ne peuvent être remplacés. Du coup on procède différemment, via un traducteur d'évènements le SLF4JBridgeHandler qui redirige tous les appels devant passer par JUL vers l'API SLF4J. Mais attention cela induit un très gros problème de performance puisque tous les évènements de logs vont être traduits et transmis à SLF4J indépendamment de si la configuration de l'API permet de les afficher ou pas. Ce problème ne sera résolu que lors du passage à Logback.

Pour mettre en place le SLF4JBridgeHandler voici la marche à suivre:

1. s'assurer que la librairie jul-to-slf4j soit bien dans les dépendances par défaut du projet
2. faire en sorte que les méthodes statiques removeHandlersForRootLogger() puis install() de la classe SLF4JBridgeHandler soient exécutées au démarrage de l'application.

Cette dernière étape peut se faire soit programmatiquement, dans le main d'une application standalone ou dans un bean s'exécutant au démarrage d'une application plus complexe, soit via de la configuration et par exemple dans le cadre d'un projet spring, en ajoutant ce qui suit dans la configuration xml:

	<!-- Déclaration Bridge JUL -->
	<bean id="slf4JBridgeHandler" class="org.slf4j.bridge.SLF4JBridgeHandler" init-method="removeHandlersForRootLogger" />
	<bean class="org.slf4j.bridge.SLF4JBridgeHandler" init-method="install" depends-on="slf4JBridgeHandler" />	

Le plus simple est de faire un commit de votre code. A défaut, un zip de votre projet fera tout aussi bien l'affaire.

Cet outil, qui se nomme slf4j-migrator va:

• supprimer tous les imports portant sur JUL, log4j ou commons-logging et les remplacer par l'import des classes correspondantes de slf4j
• remplacer de la même manière les déclarations de loggers dans le code.
• modifier toutes les occurences où l'on appelle le logger pour utiliser la méthode équivalente de slf4j

Mais il ne faut pas s'attendre à des miracles, il y aura forcément des cas ambigus et des erreurs qui vous seront normalement remontés par votre IDE. Ces problèmes font l'objet du prochain paragraphe.

Plusieurs types de problèmes peuvent être rencontrés par l'outil de migration, qui n'est pas extrêmement malin (utilisez votre IDE pour tracer tous les endroits où sont apparues des erreurs java):

• Il peut rencontrer des ambiguités au moment de choisir les niveaux de log à appeler. Par exemple, selon les projets, les niveaux de logs FINE, FINER et FINEST de JUL se répartiront différemment entre les niveaux slf4j TRACE et DEBUG
• Il peut rater complètement une déclaration de log qui aura été justifiée sur deux lignes, et qu'il faudra alors reprendre à la main
• Il y a également le cas où l'appel sur le logger contenait autre chose qu'une String, un cas de figure qu'il ne sait pas gérer et qu'il faut là aussi reprendre manuellement.

Dans la dernière hypothèse, si à la place d'une chaine de caractère, un objet est passé en argument au logger (typiquement une exception), le plus simple pour résoudre le problème est d'appeler explicitement la méthode toString() (ce qui était de toute manière le cas de manière implicite avec commons-logging)

Par ailleurs il y a aussi tous les messages de journalisation un petit peu construits que nous avons évoqués au III 1). Grâce au passage à slf4j, on peut désormais remplacer tous les appels de type

		 if (logger.isDebugEnabled()) { // pour éviter que la JVM perde du temps à construire le message dans le cas où le DEBUG n'est pas actif
		logger.debug("problème avec le user "+username+" (commande n°"+numCommande+", sessionid="+sessionid+")");	

par un code équivalent tel que le suivant, qui est beaucoup moins lourd syntaxiquement et ne pose pas davantage de problème de performance que le précédent:

	logger.debug("problème avec le user {} (commande n°{}, sessionid={})",username,numCommande,sessionid);	

En effet, lors de l'appel de la méthode, l'API va commencer par vérifier si le niveau correspondant de journalisation est actif pour cette classe avant de construire le message de log d'après les arguments qui lui sont passés.

Mais là aussi, l'outil de migration n'est pas assez malin pour le faire automatiquement, ça fait donc partie des choses à reprendre à la main.

	<!-- Log4J Configuration -->
<appender name="myAppender" class="org.apache.log4j.RollingFileAppender">
    <param name="File" value="${catalina.base}/logs/myApp.log" />
    <param name="Append" value="true" />
    <param name="MaxFileSize" value="20MB" />
    <param name="MaxBackupIndex" value="10" />
    <layout class="org.apache.log4j.PatternLayout">
        <param name="ConversionPattern" value="%d %X{param} %-5p %m%n" />
    </layout>
       <filter class="org.apache.log4j.varia.StringMatchFilter">
              <param name="StringToMatch" value="PATTERN1" />
              <param name="AcceptOnMatch" value="true" />
      </filter>
      <filter class="org.apache.log4j.varia.StringMatchFilter">
              <param name="StringToMatch" value="PATTERN2" />
              <param name="AcceptOnMatch" value="true" />
      </filter>
    <filter class="org.apache.log4j.varia.DenyAllFilter"/>
</appender>	

On part d'un appender log4j de type RollingFileAppender: il sert à écrire dans un fichier myApp.log, lequel doit être renommé en myApp.log.1 lorsqu'il atteint les 20MB, l'appender écrivant dés lors dans un nouveau fichier myApp.log, et ainsi de suite jsuqu'à à voir 10 fichiers myApp.log.x. Au delà de cette limite le fichier le plus ancien est effacé lorsqu'un nouveau fichier est créé. Cette configuration est particulièrement prisée en production, elle permet de garantir que l'espac disque dédié aux logs n'excèdera pas 220MB tout en conservant un certain historique.
De plus, on a configuré cet appender pour n'accepter que certains types de messages: ceux qui contiennent les mots clés PATTERN1 et PATTERN2 et pour rejeter tous les autres.

	<appender name="myAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${catalina.base}/logs/myApp.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
        <fileNamePattern>${catalina.base}/logs/myApp.log.%i</fileNamePattern>
        <minIndex>1</minIndex>
        <maxIndex>10</maxIndex>
    </rollingPolicy>
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
        <maxFileSize>20MB</maxFileSize>
    </triggeringPolicy>
    <filter class="ch.qos.logback.core.filter.EvaluatorFilter">      
        <evaluator> <!-- defaults to type ch.qos.logback.classic.boolex.JaninoEventEvaluator -->
            <expression>return message.contains("PATTERN1");</expression>
        </evaluator>
        <OnMismatch>NEUTRAL</OnMismatch>
        <OnMatch>ACCEPT</OnMatch>
    </filter>
    <filter class="ch.qos.logback.core.filter.EvaluatorFilter">      
        <evaluator> <!-- defaults to type ch.qos.logback.classic.boolex.JaninoEventEvaluator -->
            <expression>return message.contains("PATTERN2");</expression>
        </evaluator>
        <OnMismatch>DENY</OnMismatch>
        <OnMatch>ACCEPT</OnMatch>
    </filter>
    <encoder>
        <pattern>%d %X{param} %-5p %m%n</pattern>
    </encoder>
</appender>	

Cet appender est strictement équivalent au précédent en fonctionnalité. Il est légèrement plus verbeux, mais également plus souple au niveau des possibilités de configuration. Par exemple il est tout à fait possible de définir un dossier différent pour le fichier de log courant myApp.log et pour les déclinaisons archivées myApp.log.x, et il est également possible de définir un autre pattern de nommage, par exemple myApp.log-x.

Pour pouvoir utiliser des filtres avancés tels que les EvaluatorFilter il est nécessaire d'ajouter dans les dépendances du projet les artefacts janino et commons-compiler (de même version que slf4j)

La balise configuration en début du fichier logback.xml supporte un certain nombre de paramètres parmi lesquels scan et scanPeriod, qui permettent de définir si le fichier doit se recharger automatiquement (par défaut, non), et à quel intervalle. Exemple:

	<configuration scanPeriod="10 seconds" scan="false">	

Notez que si l'unité de scanPeriod n'est pas spécifiée, celle par défaut est la milliseconde. Notez également le coût en terme de performances n'est pas neutre dans certains cas. Des optimisations ont été apportées pour le limiter au maximum, avec pour conséquence qu'il peut y avoir une petite latence supplémentaire au délai spécifié dans le paramètre scanPeriod entre le moment où le fichier modifié est sauvegardé et le moment où le changement est observé dans les logs.

L'autre solution pour modifier un niveau de log à chaud est de le faire via JMX. Pour ce faire il suffit que votre application soit configurée pour le JMX, et d'ajouter dans le fichier logback.xml la ligne suivante:

	<jmxConfigurator />	

Cela va permettre de modifier les niveaux de log à l'aide de la jconsole

Il est possible de mettre des structures de controles dans le fichier logback.xml. Par exemple:

	<!-- Pour qu'il n'y ait pas de problème lorsque logback n'est pas utilisé depuis un tomcat -->
	<if condition='isDefined("catalina.home")'>
        <then>
            <property name="log.folder" value="${catalina.home}/logs"/>
        </then>
        <else>
            <property name="log.folder" value="./target/logs"/>
        </else>
    </if>	

En plaçant ce morceau de code en début du fichier logback.xml il devient par la suite possible d'utiliser le paramètre ${log.folder} dans tous les appenders déclarés ensuite ce qui est assez pratique.

Il est possible d'activer le mode debug de logback en ajoutant `debug="true"` dans la balise configuration. Les informations correspondant au fichier qui est lu et à la manière dont il est interprété seront alors affichées dans la sortie standard à chaque rechargement, ce qui est pratique au moins au début pour comprendre ce qui se passe.

Un exemple vaut mieux qu'un long discours:

	java -Dlogback.configurationFile=/path/to/config.xml chapters.configuration.MyApp1	

Les premières versions de logback, jusqu'à la 1.1.4 le faisaient par défaut. Cela permet d'obtenir ce genre de stack:

	14:28:48.835 [btpool0-7] INFO  c.q.l.demo.prime.PrimeAction - 99 is not a valid value
java.lang.Exception: 99 is invalid
  at ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/:na]
  at org.apache.struts.action.RequestProcessor.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]
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12]
  at ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/:na]
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar:6.1.12]
  at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]	

Il faut désormais ajouter le paramètre `packagingData="true"` dans la balise configuration du fichier logback.xml pour l'activer.