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.
É 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?)
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.
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.
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.
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.
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ê.
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.
Respostas:
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.
fonte
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?)
fonte
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.
fonte
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 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.
fonte
Sua decisão deve ser baseada em
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ê.
fonte
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.
fonte