RFWLogger

O RFWLogger é um serviço de "log" do framework com o objetivo de realizar o registro de informações do sistema para os desenvolvedores. O desenvolvedor deve chamar o RFWLogger sempre que alguma informação quiser registrar alguma informação similar a qualquer outro framework de Log. Além da possibilidade de imprimir no console, este serviço permite que o log seja organizado em banco de dados para uma melhor filtragem e análise do fluxo por sessão do usuário.

Log Recursivo Na Persistência Um dos problemas do modelo do RFWLogger é que ele não permite que o RFWLogger seja utilizado nas classes que ele mesmo utiliza. Como no caso dos métodos do RFWInterceptor e do RFWDAO. Isso porque toda vez que o RFWLogger persistir os logs no banco, gerará novos Logs sobre a persistência, e assim por diante. Estes tipos de logs é recomendado continuar a utilizar o sistema de log em arquivo do servidor de aplicação. É possível escrever um DAO exclusivo para o RFWLogger, eliminando o problema no RFWDAO, já o problema do SessionManager#SMInterceptor necessitaria uma fachada completa só para esse fim. Nada difícil ou impossível, mas não implementado por enquanto. Consulte a classe RFWpara saber como obter se está ou não em modo desenvolvimento.

O RFWLogger se integra com a aplicação permitindo que tudo seja registrado de forma a facilitar o debug e relatórios para o desenvolvedor. Como por exemplo, podem ser inclusos no log informações de sessão - quando essas informações ocorrem dentro de uma sessão de usuário - permitindo um filtro dos logs da sessão e obtendo o passo a passo somente daquele usuário.

Estrutura do Objeto de Log

Cada evento de Log é um objeto diferente, um RFWLogEntry. Esse objeto tem dois campos diferentes para salvar mensagens: message e content. A diferença entre eles é que message sempre carrega a informação que o usuário passou no método de .log*(), enquanto que content são informações maiores, como o print de um objeto, um XML, o Stack do método que chamou o log (dependendo da Severidade não é colocado).

Tags

O RFWLogEntry tem ainda um conjunto de Tags. Essas tags podem ser passadas pelo desenvolvedor durante a chamada do método .log*() para identificar os registros (permitindo filtros posteriores). Algumas tags são definidas automaticamente pelo próprio RFWLogger. As tags automáticas são:

• Caso estejamos utilizando o RFWSessions para controlar a sessão de autenticação, o label do usuário é colocado como tag;
• Caso tenha sido inicializado no RFW, o nome da aplicação também é colocado como uma tag;

Funcionamento

O RFWLogger é uma classe estática e pode ser usada a qualquer momento. Todas as chamadas aos métodos .log*() criam entradas de log automaticamente que ficam armazenadas em uma lista dentro do próprio RFWLogger.

O módulo não persiste nem salva seus logs em nenhum lugar além da memória. O sistema deve implementar e inicializar uma Thread que consume os logs, persistindo-os onde achar melhor (banco de dados, arquivos, etc.) o mais rápido possível para evitar o consumo da memória, e ao mesmo tempo cuidando para que esse evento não gere problemas de performance.

Em resumo o RFWLogger oferece uma simples ferramenta para abstrair a maneira de realizar logs em todo o sistema e deixar que o sistema implemente como fará a persistência e análise dessas informações.

Configuração

Por ser uma classe estática, ela tende a funcionar de forma uniforme pelo sistema inteiro. Porém, é preciso tomar cuidado com o escopo criado pela JVM. Dependendo do servidor de aplicações, as instâncias antes e depois da fachada podem ou não compartilhar os mesmos objetos estáticos em memória. Em casos de termos ambientes isolados, é necessário instanciar e o RFWLogger em todos os escopos.

A classe contém alguns atributos estáticos que ajudam a configurar o módulo:

• timeToLive - define o tempo em segundos máximo que um log será mantido em memória esperando ser consumido. Caso um registro ultrapasse esse tempo de vida ele será automaticamente descartado para que não tenhamos um estouro de memória. Esse tempo deve ser maior que o tempo definido na Thread de consumo e persistência desenvolvida pela aplicação.
• timeToClean - define o tempo em segundos que a Thread interna do RFWLogger é chamada para verificar a existência de logs antigos

CleannerThread

O módulo possui uma Thread Daemon de limpeza automática dos logs em memória. Ela funciona como um backup para o caso da thread de consumo falhar. Ela se baseia nos parâmetros timeToLive e timeToClean.

Note que esta é uma Thread de "safe", caso a aplicação não consuma e persista os logs corretamente. A aplicação deve ter uma Thread que consuma os logs, persista-os e já os remova do RFWLogger.

Thread de Consumo e Persistência

A thread de consumo deve ser implementada conforme especificações do sistema. Ela deve chamar o método getEntriesList() para obter todos os objetos de registro. Após registrar, ela deve passar a mesma lista para o método removeEntries() para remover os registros do RFWLogger. Inicialmente a operação foi desenvolvida em dois passas para que em caso de falha da Thread, os objetos não sejam perdidos. Caso a opção seja trabalhar no sistema "best effort", é possível utilizar o método popEntriesList() que obtém a lista e já os remove do módulo.

Logs da Thread de Consumo Atenção para os logs realizados dentro desta thread, inclusive dentro dos métodos que ela invoca, pois caso ela crie mais registros dentro do RFWLogger o sistema estará retro-alimentando um ciclo que não só não para como pode crescer até o travamento do sistema!