log4j vs logback [fechado]

152

Estamos usando o log4j atrás de um wrapper selfmade. Planejamos usar muito mais recursos agora.

Devemos atualizar para o logback?

(Quero dizer, o quadro não é uma fachada como SLF4J)

Jonik
fonte
1
o logback soa muito semelhante ao jakarta commons log - quais são as principais diferenças?
Matt b
12
O SLF4J (que é a fachada) soa semelhante ao commons.logging. A principal diferença é que o SLF4J está usando ligação estática enquanto commons.logging está usando alguma estratégia de resolução. O logback (a implementação "nativa" (ou seja, não há camada adicional do wrapper) da fachada) é comparável ao LOG4J, mas possui uma API mais rica.
Huxi

Respostas:

190

O logback implementa nativamente a API SLF4J. Isso significa que, se você estiver usando o logback, estará realmente usando a API do SLF4J. Teoricamente, você poderia usar os elementos internos da API de logback diretamente para o log, mas isso é altamente desencorajado. Toda a documentação e exemplos de logback em registradores são escritos em termos da API SLF4J.

Portanto, usando o logback, você estaria realmente usando o SLF4J e, por qualquer motivo, queira voltar ao log4j, poderá fazê-lo em questão de minutos, simplesmente colocando o slf4j-log4j12.jar no caminho da sua classe.

Ao migrar do logback para o log4j, partes específicas do logback , especificamente aquelas contidas no arquivo de configuração logback.xml , ainda precisam ser migradas para o seu equivalente log4j, ou seja, log4j.properties . Ao migrar na outra direção, a configuração do log4j, ou seja , log4j.properties , precisaria ser convertida em seu equivalente de logback. Existe uma ferramenta on-line para isso. A quantidade de trabalho envolvida na migração de arquivos de configuração é muito menor do que o trabalho necessário para migrar as chamadas do criador de logs disseminadas por todo o código-fonte do software e suas dependências.

Ceki
fonte
28
É uma oportunidade real de conversar com o desenvolvedor de um software tão popular. Obrigado Ceki por log4j.
Srujan Kumar Gulla
7
Disclaimer: Esse cara é o desenvolvedor original de todos os Log4j, SLF4J e Logback. Mas não trabalhe mais no Log4j.
Victor Stafusa
56

Você deveria? Sim .

Por quê? Log4J foi essencialmente descontinuado pelo Logback .

Isso é urgente? Talvez não.

É indolor? Provavelmente, mas isso pode depender de suas instruções de log.

Observe que se você realmente deseja tirar o máximo proveito do LogBack (ou SLF4J), precisará realmente escrever instruções de log apropriadas . Isso trará vantagens como código mais rápido por causa da avaliação lenta e menos linhas de código, porque você pode evitar guardas.

Finalmente, eu recomendo o SLF4J. (Por que recriar a roda com sua própria fachada?)

AWhitford
fonte
48
Nota: O projeto log4j não considera o log4j descontinuado.
Thorbjørn Ravn Andersen 10/10
17
A terminologia deve ser esclarecida; inequivocamente, o autor do projeto log4j considera o logback o sucessor do log4j. É o mesmo autor dos dois projetos, por isso a opinião dele deve ter algum peso; o próprio "projeto log4j" realmente não "considera" nada. O atual grupo de pessoas associadas ao log4j tem opiniões divergentes (algumas realmente concordam, outras, sem surpresa). Com um pouco mais de história para trás (3 anos após o comentário original), o SLF4J + Logback continua a ganhar terreno sobre o Log4j.
22613 Michael
@michael_n Observe que o Log4j 1 NÃO foi escrito por uma única pessoa. É errado dizer o "mesmo autor". Ceki é um autor importante, sem dúvida, mas não o único. De fato, muitas pessoas ajudaram a tornar o Log4j 1 o que é.
Christian
@Christian "NÃO foi escrito ..." é claro, isso deve estar implícito em qualquer projeto maduro do apache (e na minha qualificação ", o atual grupo de pessoas associado ao log4j"); no entanto, se eu pudesse editar o comentário, diria "de autoria original ", como também declara o artigo da Wikipedia. Re: "De fato, muitas pessoas ajudaram a tornar o Log4j 1 o que é" , isso é absolutamente equivocamente verdadeiro (isto é, para melhor ou para pior); e também, de alguma forma, contribuíram para a criação de slf4j + logback :-)
michael
3
Então, o que há para todos vocês brigarem por essa ou aquela biblioteca de registro? Por que estamos tentando matar / promover bibliotecas? Pelo menos forneça algum raciocínio racional POR QUE um é melhor que o outro. Deus, estouro de pilha é uma bagunça.
Usuário
48

No mundo dos logs, existem Fachadas (como Apache Commons Logging, slf4j ou até a API Log4j 2.0) e implementações (Log4j 1 + 2, java.util.logging, TinyLog, Logback).

Basicamente, você deve substituir seu invólucro selfmade por slf4j IF e somente se você não estiver satisfeito com ele por algum motivo. Enquanto o Apache Commons Logging não está realmente fornecendo uma API moderna, o slf4j e a nova fachada do Log4j 2 estão fornecendo isso. Como vários aplicativos usam o slf4j como invólucro, pode fazer sentido usá-lo.

O slf4j fornece uma série de ótimos açúcares de API, como este exemplo do slf4j docs:

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

É substituição variável. Isso também é suportado pelo Log4j 2.

No entanto, você precisa estar ciente de que o slf4j é desenvolvido pelo QOS, que também mantém o logback. O Log4j 2.0 é instalado na Apache Software Foundation. Nos últimos três anos, uma comunidade vibrante e ativa cresceu lá novamente. Se você aprecia o Open Source, como é feito pela Apache Software Foundation, com todas as suas garantias, pode reconsiderar o uso do slf4j em favor do Log4j 2 diretamente.

Observe:

No passado, o log4j 1 não era mantido ativamente enquanto o Logback era. Mas hoje as coisas são diferentes. O Log4j 2 é mantido ativamente e é lançado com agendamento quase regular. Ele também inclui muitos recursos modernos e -imho- faz algumas coisas melhores que o Logback. Às vezes, isso é apenas uma questão de gosto e você deve tirar suas próprias conclusões.

Escrevi uma rápida visão geral sobre os novos recursos do Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html

Ao ler, você verá que o Log4j 2 foi inspirado pelo Logback, mas também por outras estruturas de registro. Mas a base de código é diferente; ele compartilha quase nada com o Log4j 1 e zero com o Logback. Isso levou a algumas melhorias, como no exemplo, o Log4j 2 opera com bytestreams em vez de Strings under the hood. Também não perde eventos durante a reconfiguração.

O Log4j 2 pode registrar com maior velocidade do que outras estruturas que conheço: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html

E ainda a comunidade de usuários parece ser muito maior que o Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html

Dito isso, a melhor idéia é escolher as estruturas de registro que melhor se ajustam ao que você deseja alcançar. Eu não mudaria uma estrutura completa se desativasse o log no ambiente de produção e apenas realizasse o log básico no meu aplicativo. No entanto, se você fizer um pouco mais com o registro, observe os recursos fornecidos pelas estruturas e seus desenvolvedores. Enquanto você obtém suporte comercial para o Logback por meio do QOS (ouvi dizer), atualmente não há suporte comercial para o Log4j 2. Por outro lado, se você precisar fazer o log de auditoria e precisar de alto desempenho fornecido pelos apêndices assíncronos, faz muito sentido verifique log4j 2.

Observe que, apesar de todo o conforto que eles oferecem, as fachadas sempre apresentam um pouco de desempenho. Talvez não esteja afetando você, mas se você estiver com poucos recursos, poderá precisar salvar tudo o que puder.

Sem conhecer melhor os requisitos, é quase impossível fazer uma recomendação. Apenas: não mude só porque muitas pessoas mudam. Mude apenas porque você vê o valor dela. E a argumentação de que log4j está morto não conta mais. Está vivo e está quente.

AVISO LEGAL: Atualmente, sou VP, Apache Logging Services e também estou envolvido no log4j.

cristão
fonte
19

Não está respondendo exatamente à sua pergunta, mas se você puder se afastar do seu invólucro criado por si mesmo, existe o SLF4J (Simple Logging Facade for Java) para o qual o Hibernate agora mudou (em vez de logon comum).

O SLF4J não sofre com nenhum dos problemas do carregador de classes ou com vazamentos de memória observados no Jakarta Commons Logging (JCL).

O SLF4J suporta log JDK, log4j e logback. Portanto, deve ser bastante fácil alternar do log4j para o logback quando for a hora certa.

Edit: Aplogies que eu não tinha me deixado claro. Eu estava sugerindo o uso do SLF4J para se isolar de ter que fazer uma escolha difícil entre log4j ou logback.

kit de ferramentas
fonte
3
Eu sei SLF4J. Mas eu pedi a estrutura de registro e não a fachada!
4
Desculpas. O que eu estava sugerindo era que, se você estivesse usando SLF4J em vez de sua própria fachada personalizada, alternar do log4j para o logback seria menos doloroso?
toolkit
Qual é a fonte dessa citação? O registro do Commons é um componente testado e comprovado. Eu nunca tive nenhum vazamento de memória com isso.
Kshitiz Sharma
1
@KshitizSharma - no link da documentação do SLF4J que forneci: slf4j.org/manual.html
toolkit
13

Sua decisão deve ser baseada em

  • sua necessidade real desses "mais recursos"; e
  • seu custo esperado para implementar a alteração.

Você deve resistir ao desejo de alterar as APIs apenas porque é "mais novo, mais brilhante, melhor". Sigo uma política de "se não estiver quebrado, não chute".

Se o seu aplicativo exigir uma estrutura de log muito sofisticada, considere o porquê.

Carl Smotricz
fonte
3

Um projeto maduro ou mesmo profundo nos estágios de desenvolvimento provavelmente perderia mais do que ganhos com essa atualização, IMHO. O Logback certamente é muito mais avançado em uma variedade de pontos, mas não a uma extensão para a substituição completa em um sistema em funcionamento. Eu certamente consideraria o logback para um novo desenvolvimento, mas o log4j existente é bom o suficiente e amadurece para qualquer coisa que já tenha sido lançada e atendida pelo usuário final. Isso é muito subjetivo, você deve ver o custo.

Dima
fonte