Java e log4j2: una prova aspettando qualcosa di definitivo

Sembra che qualcuno si sia rimesso a lavorare su log4j2. Non sono riuscito a trovare una roadmap sulla homepage, ma dalla pagina di sonar relativa a log4j2 si intravede che:

09-09-2013	Version	2.0-beta9-SNAPSHOT	
10-07-2013	Version	2.0-beta8-SNAPSHOT	
31-05-2013	Version	2.0-beta7-SNAPSHOT	
05-05-2013	Version	2.0-beta6-SNAPSHOT	
20-04-2013	Version	2.0-beta5-SNAPSHOT	
28-01-2013	Version	2.0-beta4-SNAPSHOT

qualcosa si sta muovendo. A detta loro Log4j 2 è molto meglio di log4j 1.x (e vorrei vedere il contrario) e di logback:

Log4j 2 contains next-generation Asynchronous Loggers based on the LMAX Disruptor library. In multi-threaded scenarios Asynchronous Loggers have 10 times higher throughput and orders of magnitude lower latency than Log4j 1.x and Logback. See Asynchronous Logging Performance for details. Otherwise, Log4j 2 performs faster than Log4j 1.x in critical areas and similarly to Logback under most circumstances

Dopo aver dato una sbirciata veloce, ho fatto un piccolo progetto di esempio. Le dipendenze sono queste:

  <dependencies>
     <dependency>
       <groupId>org.apache.logging.log4j</groupId>
       <artifactId>log4j-api</artifactId>
       <version>2.0-beta8</version>
     </dependency>
     <dependency>
       <groupId>org.apache.logging.log4j</groupId>
       <artifactId>log4j-core</artifactId>
       <version>2.0-beta8</version>
     </dependency>
   </dependencies>

E cambia poco nella sua dichiarazione di base:

private static Logger logger = LogManager.getLogger("Progetto");

E’ possibile, in maniera similare a log4j1.x, configurare log4j2 utilizzando un file di configurazione, che in questo caso si chiama log4j2.xml, per esempio fatto così:

<?xml version="1.0" encoding="UTF-8"?>
<configuration status="WARN">
  <appenders>
    <Console name="Console" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
    </Console>
  </appenders>
  <loggers>
    <root level="all">
      <appender-ref ref="Console"/>
    </root>
  </loggers>
</configuration>

che, in questo caso, vi permette di vedere tutti i messaggi in console. Da notare che se viene trovato il file log4j2-test.xml nel classpath viene utilizzato quello al posto del log4j2.xml.

Qualche novità veloce:

1) La sostituzione dei parametri

Hanno aggiunto la sostituzione dei parametri, se ho capito bene ottimizzando la concatenazione in maniera similare a logback:

String s = "Si stava meglio quando si stava peggio";
logger.debug("Questo è il valore di s: {}", s);
logger.debug("Questo è il valore di s: " + s);

Il risultato è lo stesso, ma la differenza è sostanziale. Usando le graffe per la sostituizione la concatenazione fra le due stringhe viene fatta solo se il livello di debug specificato è abilitato. Nel caso di utilizzo di “+” la concatenazione viene fatta in ogni caso.

2) La formattazione dei parametri

E’ possibile formattare i parametri, utilizzando una istanza di un “coso” chiamato FormatterLogger con la stessa sintassi della classe java Formatter:

private static Logger loggerFormattoso = LogManager.getFormatterLogger("Esempio2");
 
String s = "Nicola";
loggerFormattoso.debug("Ciao, Il mio nome è %s e non bevo dal %s", s, new Date());
loggerFormattoso.debug("Integer.MAX_VALUE = %,d", Integer.MAX_VALUE);
loggerFormattoso.debug("Long.MAX_VALUE = %,d", Long.MAX_VALUE);

3) Il nome di default del logger

Se non si specifica il nome del logger, in questo modo

private static Logger logger = LogManager.getLogger();
 
logger.info("Tadaa");

viene utilizzato di default il percorso completo della classe:

22:56:55.507 [main] INFO  it.nicola.esempi.esempiolog4j2.Esempio3 - Tadaa

Geniale no?

Il tutto viene fornito a corredo di un bridge per utilizzare log4j2 come implementazione di slf4j.

In sostanza:

L’accoppiata slf4j/logback per il momento ha definitivamente soppiantato log4j 1.x, ma log4j2 è sicuramente da approfondire. Chi non ha ancora passato vecchie applicazioni da log4j 1.x a framework più recenti può aspettare per vedere se il progetto vedrà una release stabile a breve. Oppure continua a usare quello che sta usando perchè in fondo la vita è breve, il tempo è denaro e quello che viene scritto nei file di log non interessa mai a nessuno.