Log4j estendido

Quanto a passar varios parametros é impossível!

O que vc pode fazer é, enviar:

logger.info("O recurso foi alterado.[[$]]"+ usuarioLogado +"[[$]]"+ recurso +"[[$]]"+ recurso.getStatus());

Ai na tabela em que vai ser guardada esta informação, vc faz um trigger que faz o split por “[[$]]” e guarda a informação como bem entender…

No H2DataBase podes fazer uma trigger com código Java.

Mas em qualquer DB vc pode fazer isto tanto usando SQL ou usando Java como no caso do H2DataBase.

Há… e aconselho ter uma classe mais ou menos assim para gravar os logs:

public class BusinessLog { private static Logger logger = Logger.getLogger(BusinessLog.class); public static void info(String msg, String usuario, String recurso, String recursoStatus) { logger.info(msg +"[[$]]"+ usuario +"[[$]]"+ recurso +"[[$]]"+ recursoStatus); } }

Assim se quiser mudar o separador é mais fácil, além de também ser mais fácil detectar o tipo dos logs, sendo eles sempre da mesma classe.

Hmm, tinha pensando nisso…
Mas aí vc tá concatenando os objetos à mensagem. Depois tem que quebrar as mensagem pra recuperar os valores.
Bom, é uma solução rápida, mas não parece meio POG não?!

(POG = Programação da Orientada a Gambiarra! rs )

[]s

O log4j aceita qualquer objeto como mensagem, mas no fim ele só guarda o toString.
Para alterar isso vc precisa costumizar o log4j com Fortmatters e Appenders apropriados

Footmatters?? :?
O que seria?

Pois é, imaginei que tivesse que estendê-lo mesmo.
Mas como eu faria isso?

uchoaaa:

Footmatters?? :?
O que seria?

Pois é, imaginei que tivesse que estendê-lo mesmo.
Mas como eu faria isso?

Desculpa não é formater é layout
( http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Layout.html)

Como faria isso ? Herdando a classe Layout do Log4j.

Opa, valeu.
Tava dando uma olhada no material do site justamente agora.

Mas aí eu teria que estender também o LogginEvent, não é?! Visto que agora meus eventos de logs também utilizam objetos de negócio… :?

Viugi, se assim for, vai ficar meio complicado…

uchoaaa:

Opa, valeu.
Tava dando uma olhada no material do site justamente agora.

Mas aí eu teria que estender também o LogginEvent, não é?! .

Não. O LogginEvent transporta o objeto passado em logXXX() com mais algumas informações como data , thread, etc…

quando vc loga vc passa o objeto de negocio logger.logInfo (ObjetoNegocio) e depois vc pega ele de volta com getMessage()
em LogginEvent dentro do layout. Ai vc faz um cast e trabalha normalmente com ObjetoNegocio

Estude bem a API do log4j que é muito bem arquitetada.

uchoaaa:

Salve todos.
Bom, agora eu preciso de algo mais. Preciso de logs que gerem “informações de negocio” mesmo.
Como quem acessou tal recurso, quando, por quanto tempo, etc. Informações que vão servir de base para relatórios, ajudar na tomada de decisões.

IMO, vc. não deve usar o log4j ou qualquer API de log para este fim. Pelo que entendi, vc. quer uma espécie de trilha de auditoria e fazer isto via log possui alguns inconvenientes:

1. Depende da inserção de chamadas nos pontos corretos do código
2. No caso do log4j e outros, o destino das mensagens pode ser manipulado em tempo de execução, o que representa um risco de segurança

A melhor abordagem é a utilizada por produtos como o Guardium, que interceptam e gravam em um banco de dados separado todo o tráfego SQL entre sua aplicação e o banco. Como não é todo mundo que tem “bala na agulha” para bancar uma solução destas, uma alternativa viável é vc. utilizar AOP ou criar um “proxy driver” que intercepte as chamadas JCBC e armazene a informação “bruta” dos comandos executados em uma base distinta da utilizada pela aplicação. A partir dos dados brutos, vc. criaria um pós-processador para obter as informações gerenciais necessárias.

Não, não, não é bem por aí.
Não são todas as requisições ao banco que precisam ser monitoradas. Não precisa dessa trilha, como vc chamou.
Na verdade, depende sim da inserção de chamadas nos pontos corretos do código. São operações bem pontuais que seriam registradas.

A aplicação precisa registrar quando um determinado recurso foi consumido. Na prática, toda vez que um Vídeo for requisitado para exibição, deve-se salvar no banco a data e hora dessa requisição, qual Vídeo foi requisitado e por quem, que é o usuário logado.

A aplicação é Web, MVC, sem muito espaço para AOP, na minha humilde opinião. (Até porque não trabalho com AOP
Penso em criar um logger específico com um JDBCAppender. Ou mesmo uma utilizar um POJO que amarre essas informações e salve via JDBC mesmo…

O que me dizem??

Bem, isto, para mim, caracteriza uma trilha de auditoria ;^) A questão básica é se o log será utilizado para fins de negócio ou não. Se for, mantenho minha opinião: log4j e assemelhados não são adequados - que não quer dizer que não possam ser utilizados, é claro.

AOP é mais simples de implementar do que parece, e evita ter que depender da boa vontade do programador em inserir as chamadas nos pontos corretos do código. Se há uma aplicação em que AOP vale a pena é justamente o seu cenário.

Note que um filtro (servlet filter) não deixa de ser uma implementação do conceito de AOP. Se sua aplicação possui urls específicas em que o download efetuado, vc. já tem o “pointcut” (no caso uma URI) para inserir o código que vai logar o acesso.

Hmmm… interessante, isso. Vou dar uma olhada em AOP, fiquei curioso.
Mas pra esse projeto não vai dar tempo.

Ah, outra coisa, também não tinha pensado nessa abordagem de um servlet fitler. O ‘pointcut’ seria mapeado via código, e não via URL.
O método que faz o download, chamaria um método que geraria esse registro.

Bom, uma coisa. Mapeando via URL me parece que a o registro não faz parte da lógica de negócio, ou seja, eu posso não usar mais esse Filter e o download continuar disponível. Mapeando esse ‘pointcut’ via código, eu teria o registro como parte da lógica de negócio, bem como todas as outras operações, etc. Ou seja, sem o registro, não há download!

Ou esse pensamento é errado??

[]s

Bom, uma coisa. Mapeando via URL me parece que a o registro não faz parte da lógica de negócio, ou seja, eu posso não usar mais esse Filter e o download continuar disponível. Mapeando esse ‘pointcut’ via código, eu teria o registro como parte da lógica de negócio, bem como todas as outras operações, etc. Ou seja, sem o registro, não há download!

Ou esse pensamento é errado??

[]s

Se eu entendi direito, no seu caso o registro do download faz parte da regra de negócio, e este é o motivo básico de minha restrição ao uso de um mecanismo mais voltado para aspectos operacionais, como é o log4j.

Uma forma de escrever este requisito é “qualquer ação de download deve ser registrada em uma tabela específica”. Note o “qualquer”: ele é uma dica de que este é um requisito que deve ser aplicado à aplicação como um todo ou, em outras palavras, um “crosscut aspect” - daí minha recomendação de se utilizar o AOP.

Dado que vc. não tem tempo para se aventurar nisto, o filtro provavelmente lhe atenderá, mesmo que, no fim das contas, vc. use o log4j no mesmo. O ponto fundamental é evitar que, se amanhã vc. mudar por algum motivo a lógica de download, o registro não “escape” ou, no mínimo, seja simples de agregar.