Estrategia de Logs

5 respostas
Z

Ola Pessoal,

Alguem usa logs em suas aplicacoes ?

Ha alguma estrategia ou boa pratica para utilizar os logs ?

Estou trabalhando em um sistema web e utilizo o Log4j, criando a instancia:

static Logger logger = Logger.getLogger( LoginAction.class );

Nos trechos de codigo vou utilizando as mensagens:

logger.debug("Inicio do login do usuario"); ... logger.warn("Usuario nao cadastrado: ".concat( user.getName() )); ... logger.error("Erro ao acessar os dados do usuario no banco de dados");

Esse foi um pequeno exemplo. Funciona, mas nao sei se ha alguma pratica melhor.

Para toda classe eu preciso sempre instanciar com ela ? Em Logger.getLogger( LoginAction.class );
Ha alguma forma mais generica ?

Outro problema: Como ha varias empresas acessando o servidor, para saber qual a empresa disparou o log eu teria que ficar concatenando o id da empresa (e outros identificadores) sempre em cada mensagem do log ??

Agradeco comentarios e sugestoes

5 Respostas

A

Se é interesse guardar os acessos das empresas, recomendo a separação por pacotes/interfaces.

Exemplo: br.com.empresa1.cadastros.usuario (interface)
br.com.empresa2.cadastros.usuario (interface)
br.com.empresa3.cadastros.usuario (interface)
br.com.interno.cadastros.usuario (implementação)

Assim vc poderia separar os logs por pacotes (br.com.empresa1,2,3)

em arquivos separados (empresa1.log,empresa2.log,empresa3.log).

Claro que nem sempre é viavel, mas é uma estratégia válida.

Z

aleck:
Se é interesse guardar os acessos das empresas, recomendo a separação por pacotes/interfaces.

Exemplo: br.com.empresa1.cadastros.usuario (interface)
br.com.empresa2.cadastros.usuario (interface)
br.com.empresa3.cadastros.usuario (interface)
br.com.interno.cadastros.usuario (implementação)

Assim vc poderia separar os logs por pacotes (br.com.empresa1,2,3)

em arquivos separados (empresa1.log,empresa2.log,empresa3.log).

Claro que nem sempre é viavel, mas é uma estratégia válida.

Eh inviavel para nos. Nao podemos deixar a aplicacao amarrada assim.

Uma objeto empresa eh sempre o mesmo seja qual for a empresa.
Minha necessidade seria de alguma forma mais simples de mostrar qual foi a empresa em q o log foi disparado.

A

zap:

Eh inviavel para nos. Nao podemos deixar a aplicacao amarrada assim.

Uma objeto empresa eh sempre o mesmo seja qual for a empresa.
Minha necessidade seria de alguma forma mais simples de mostrar qual foi a empresa em q o log foi disparado.

O objeto empresa continua sendo o objeto empresa, porem ele ira possuir uma interface que meramente servira como mapeador para o log devido a sua posicao nos pacotes.

Voce ja deve possuir uma interface para o objeto empresa, o que estou propondo, é a criação de 1 interface para cada empresa, separadas em pacotes com o nome da empresa, assim vc poderia configurar o log4j para gravar em logs separados de acordo com o pacote.

Acredito ser uma solução mais simples do que a concatenação de ids no log.

Z

aleck:
zap:

Eh inviavel para nos. Nao podemos deixar a aplicacao amarrada assim.

Uma objeto empresa eh sempre o mesmo seja qual for a empresa.
Minha necessidade seria de alguma forma mais simples de mostrar qual foi a empresa em q o log foi disparado.

O objeto empresa continua sendo o objeto empresa, porem ele ira possuir uma interface que meramente servira como mapeador para o log devido a sua posicao nos pacotes.

Voce ja deve possuir uma interface para o objeto empresa, o que estou propondo, é a criação de 1 interface para cada empresa, separadas em pacotes com o nome da empresa, assim vc poderia configurar o log4j para gravar em logs separados de acordo com o pacote.

Acredito ser uma solução mais simples do que a concatenação de ids no log.

Entendi. Mas nao posso deixar a aplicacao amarrada com uma interface para cada empresa.

Pois a cada nova empresa que fosse aberta eu teria q alterar a aplicacao. Para uma grande organizacao isso nao eh viavel nem desejavel.

Acho q vou ter que colocar o id da empresa no log mesmo, mas agradeco pela ajuda.

R

Se não houvesse o requisito de colocar o id da empresa no log, você poderia utilizar orientação a aspectos para isolar o interesse de Log. Desta maneira, seu código ficaria mais limpo, sem códigos de log e sem precisar instanciar o Logger e ainda desacoplaria seu código retirando a dependência da API do Log4J.

Havendo o requisito de colocar o id da empresa, ainda é possível utilizar AOP se houver alguma maneira de obter tal informação através de algum método estático, mas se o id da empresa for informado como um parâmetro do método que está sendo logado, então pode ficar complicado escrever um aspecto que consiga obter essa informação.

Acho que o Aleck não percebeu que a empresa provavelmente é uma entidade persistida no banco e que em tempo de compilação não se conhece todas as empresas cadastradas (nem é admissível ter que recompilar o código toda vez que o usuário cadastre/altere/exclua uma nova empresa no sistema), o que torna inviável a solução proposta por ele.

Criado 15 de dezembro de 2008
Ultima resposta 19 de dez. de 2008
Respostas 5
Participantes 3