A Apache Software Foundation anunciou recentemente o lançamento do Log4j 2.0 GA contendo inúmeras melhorias de desempenho sobre seu predecessor, o Log4j 1.x. A nova versão levou anos para ser concluída e foi reescrita do zero, tendo como inspiração soluções de logging existentes, como o próprio Log4j 1.x e o java.util.logging.
O Log4j 2.0 introduz um novo sistema de plugins, configurações em formato JSON, resolução de propriedades (variáveis de ambiente, etc.) e recarregamento automático de configurações. Ele suporta vários frameworks de logging existentes, incluindo SLF4J, Commons Logging, Apache Flume e Log4j 1.x, além de fornecer uma nova API de programação.
O primeiro relato sobre o framework foi feito em dezembro de 2012 por Christian Grobmeier, membro do comitê da Apache Logging. Na época ele comentou sobre a API moderna:
Antigamente as pessoas escreviam códigos desta forma:
if (logger.isDebugEnabled()) { logger.debug("Hi, " + u.getA() + " " + u.getB()); }Baseado nesse tipo de exemplo, a equipe do Log4j 2.0 repensou e melhorou a API. O código anterior agora pode ser escrito desta forma:
logger.debug("Hi, {} {}", u.getA(), u.getB());
Grobmeier descreveu mais melhorias na API, incluindo Markers e Flow Tracing. Ele também mencionou as melhorias na arquitetura de plugins, melhorias na parte de configuração e como o Log4j 2.0 resolveu muitos dos problemas de deadlock da versão 1.x.
Na Hacker News, muitos reclamam da proliferação de frameworks de logging para a JVM. Ceki Gülcü, autor de vários frameworks de logging para o Java, incluindo Log4j, SLF4J e Logback, apresentou suas razões para não gostar do modelo da Apache. Gülcü ainda continua sendo um membro da comunidade e do comitê da Apache Logging.
Em julho de 2013, Grobmeier escreveu um outro post intitulado "Log4j 2: Performance close to insane". Nele, Grobmeier comenta entusiasmado como os "AsyncLoggers" criados por Remko Popma foram capazes de produzir logs doze vezes mais performáticos que outros frameworks.
Com esse resultado, a nova versão pode enviar mais de 18 milhões de mensagens por segundo, enquanto os frameworks anteriores alcançavam aproximadamente 1.5 milhão no mesmo ambiente. Esse resultado expressivo é apresentado no gráfico abaixo:
Mais informações podem ser encontradas na documentação sobre loggers assíncronos do Log4j.
Nem todos ficaram impressionados com as funcionalidades assíncronas do Log4j. Michael Rose, engenheiro sênior na FullContact, escreveu o post "Overengineering: Log4j2's AsyncAppender", onde ele conclui que não vale a pena utilizar essa funcionalidade:
Eu conclui que o AsyncAppender do Log4j 2 é apenas um brinquedo brilhante e não há realmente nenhuma diferença significativa para qualquer aplicação sensata. Tenho grande respeito pela equipe do Log4j 2, mas realmente gostaria que eles tivessem focado na construção de um framework único e coeso da próxima geração de frameworks de logging para Java em vez de adicionar apenas mais um aos já existentes.
O Logback, entretanto, implementa nativamente o SLF4J (abstração padrão para frameworks de logging) e tem um desempenho mais que aceitável (especialmente com locations ativado). Ele continua sendo o framework de logging de minha escolha. É fácil de usar e nunca tive nenhum problema com ele.
Por fim, evite o Log4j 1.x (ou qualquer coisa que não seja o Log4j 2 ou Logback) como se fosse uma praga. Em qualquer sistema com alta carga de processamento ele provavelmente será a causa de problemas de contenção.
Matt Raible recentemente atualizou o Log4j 1.x para o 2.0 na aplicação AppFuse e comentou sobre as dificuldades encontradas:
Foi difícil conseguir resolver as dependências no Maven. No mínimo é necessário o JAR log4j-core (o qual depende do log4j-api). Se estiver usando em uma aplicação web, também é necessário o log4j-web como dependência. Para fazer com que o Velocity 1.7 funcione com o Log4j 2, foi necessário incluir a log4j-1.2-api. Para fazer o Spring funcionar, tive que adicionar o log4j-jcl (Spring usa o commons-logging). Para bibliotecas que dependem do SLF4J, é necessário ainda incluir o log4j-slf4j-impl. Para fazer o Hibernate funcionar, tive que atualizar para o JBoss Logging 3.2.0.Beta1.
Pode ser preciso excluir dependências antigas do Log4j de algumas dependências. Se estiver usando Maven, o comando a seguir é uma boa forma de exibir as dependências que precisarão ser removidas.
mvn dependency:tree | grep log
Raible complementa que o último passo necessário foi renomear os arquivos log4j.xml para log4j2.xml e refatorá-los para o novo formato de configuração.
Sendo assim, o novo Log4j 2.0 tem muitas melhorias de desempenho, um novo sistema de plugins e várias outras melhorias na parte de configuração. Contudo, alguns usuários poderão (ou não) considerar essas melhorias convincentes o bastante para atualizar ou substituir uma solução de logging existente.