Esse artigo faz parte da revista Java Magazine edição 35. Clique aqui para ler todos os artigos desta edição

img

Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML. 

Cafeína

 

Recapitulando:

 

Na coluna "Java Livre" nesta edição, são apresentados frameworks de logging com enfoque no Log4j e Commons Logging. Para deixar nossa cobertura de logging completa e auto-contida, republicamos aqui, resumidamente, um artigo sobre a API java.util.logging, que saiu originalmente na Edição 5 (hoje esgotada), com o título "Logging no J2SE 1.4". O tratamento está inteiramente atual e a API não teve mudanças significativas desde então. Com o Log4j, o Commons Logging e a Logging API do Java SE, o seu arsenal de ferramentas de logging está completo!

 

Logging no Java SE

Um introdução à API java.util.logging

Como utilizar as API do Java SE para implementar e melhorar o processo de logging em aplicações Java

Neste artigo trataremos de um aspecto muito importante no desenvolvimento de software, que muitas vezes não é tratado com a devida importância: o uso de mensagens de log – ou logging. O processo de logging é muito importante, pois propicia um canal de comunicação entre a aplicação e o usuário, que pode ser usado pelos desenvolvedores na depuração de aplicações (principalmente em circunstâncias onde não é possível o uso de um software depurador). Para aplicações em  produção, o logging pode ser usado tanto para passar informações úteis ao usuário final quanto para diagnosticar o funcionamento interno da aplicação aos técnicos de suporte.

Embora existam várias soluções de logging para Java no mercado, como o excelente Log4j do projeto Apache Jakarta, somente na versão 1.4 do J2SE foi introduzida uma API para logging, que analisaremos aqui.

O que é logging?

Traduzindo ao pé da letra, “log” seria o equivalente a anotações ou registro de acontecimentos. Assim, “logging” poderia ser traduzido como o processo de registrar mensagens a partir de uma aplicação. Embora esse conceito possa parecer algo novo, ele é utilizado em muitas aplicações, muitas vezes sem nos darmos conta disso.

Na Listagem 1, por exemplo, está uma pequena aplicação que recebe como parâmetro um número inteiro e cria um servidor na porta definida pelo número passado. Note que estamos usando os objetos System.out e System.err para relatar as ações e exceções da aplicação.

Podemos dizer que o uso de System.out (e System.err) é uma forma primitiva de logging. Essa solução, no entanto, tem muitas desvantagens:

·         Falta de flexibilidade; se desejarmos mudar o comportamento do processo de logging, é necessário mudar cada chamada aos métodos de System.out e System.err;

·         As mensagens vão sempre para o mesmo destino (o console) e muitas vezes a informação é perdida – a não ser que haja um redirecionamento da saída do console para um arquivo.

·         Não há controle se o logging está habilitado ou não; as mensagens serão sempre publicadas.

·         As mensagens não recebem formatação especial (poderiam ser formatadas em XML, por exemplo) nem informações adicionais (como a hora em que foram geradas e a classe geradora).

Alternativas

Uma solução intermediária é a criação de uma classe especial para logging. Ao usar uma classe à parte, as chamadas de logging são mais simples e a flexibilidade, muito maior. Se depois decidirmos gravar as mensagens em um arquivo ou desabilitar o logging, mudamos apenas o código na classe de logging – e não em cada chamada a System.out, por exemplo.

Pois bem, a nova API de logging do J2SE 1.4 – e os outros produtos já citados – segue exatamente essa linha de raciocínio. Ela é composta pelo pacote java.util.logging (a Figura 1 mostra o diagrama de classes desse pacote).

Conceitos

Antes de continuarmos com uma descrição mais detalhada de cada classe da API de logging do J2SE, é importante apresentarmos alguns conceitos utilizados pela API:

Hierarquia – todo objeto Logger (responsável pela criação de mensagens) tem um nome e está associado a outros objetos Logger através de uma hierarquia de nomes. Se um objeto tem o nome a, ele é o pai do objeto a.b nessa hierarquia. O significado da hierarquia fica a cargo do desenvolvedor, mas o ideal é seguir a estrutura de pacotes da aplicação; outra opção é organizar os objetos segundo suas funcionalidades (por exemplo: aplicacao.rede, empresa.framework.ejb). Além disso, cada objeto herda algumas características de seus ancestrais (como o nível de log), mas essas características podem ser redefinidas.

Nível de log – toda mensagem de log (LogRecord na API) tem um nível associado a ela, que determina se a mensagem será publicada ou descartada (veja mais sobre isso adiante). ...

Quer ler esse conteúdo completo? Tenha acesso completo