BISLogger

O BISLogger é um serviço de "log" do sistema com a função de realizar o registro de informações do sistema para os desenvolvedores. O desenvolvedor deve chamar o BISLogger sempre que alguma informação deva ser registrada ou informada para ajudar a encontrar problemas no sistema ou mesmo auxilia-lo durante a fase de desenvolvimento para visualizar o fluxo que o sistema tomou sem ter que debugar de linha em linha. Além da possibilidade de imprimir no console, este serviço é responsável por salvar em banco todas as informações necessárias em caso de erros e/ou outros acontecimentos do sistema. Distinguindo as informações importantes das desnecessárias para evitar um "flood" no banco de logs e transformando o BISLogger em um registro de uso do sistema.

Com base nessas informações e em seu filtro de importância dos registros, o BISLogger é responsável também por filtrar e informar automaticamente a equipe de desenvolvimento sobre erros que acontecem no sistema sem que o usuário tenha que se incomodar com isso.

Os benefícios deste serviço é proporcionar a equipe de desenvolvimento informações mais precisas sobre os erros do que as informações desconexas normalmente provenientes dos usuários, além de ter certeza de ser notificado de toda falha do sistema. Evitando que usuários deixem de informar sobre os erros e acabem descontentes com o sistema.

Registro

Registro de Mensagens de Texto

Na classe principal do BISLogger existem 4 métodos principais, estes registram mensagens em 4 categorias diferentes. São elas:

• error - É uma mensagem de problemas encontrados no sistema, algo anormal que deve ser levado em consideração.
• warn - Warning é uma mensagem de aviso, quando algo não está como esperado mas não deverá causar nenhum erro nos sistema. Já tem uma relevância maior que a info.
• info - Informações simples a serem exibidas no console para mostrar ao desenvolvedor sobre o que o sistema está fazendo, de forma genérica e mesmo sem muitos detalhes. Exatamente um "System Out".
• debug - Este tipo de mensagem é uma mensagem detalhada, com anotações dos objetos e detalhes da execução de um método. Geralmente usada para rastreamento preciso de algum erro que esteja acontecendo no sistema e não esteja simples de se detectar.

Registro de Mensagens Especiais

• report - O tipo de registro Report é registrado separado do relatório da Thread padrão do BISLogger. Ele é identificado por um ID passado no primeiro parâmetro do método. Os registros sucessivos utilizando o mesmo ID de relatório serão somados em um único Log até que este seja finalizado por inatividade, ou forçado no shutdown/undeploy do sistema. Independente da Thread que o faça o log, todos os farão parte do mesmo relatório. A ideia é possibilitar o registro em um mesmo relatório quando o sistema está distribuído em Threads.

Registro de Exceptions

Além do registro de mensagens simples descritos anteriormente, o BISLogger apresenta métodos para registrar Exceções de forma simples! Basta chamar seu método e passar a exceção ocorrida, seu stack trace será recuperado e registrado junto com a mensagem.

Registro de VOs

Em alguns casos pode haver a necessidade de se registrar os VOs completo do sistema para saber o que está causando o erro. Para tal o BISLogger dispõe de um método que lê e imprime qualquer VO do sistema. Neste caso deve ser descendente de BISDefaultVO.

Auto-Debugger

Com a finalidade de registrar em detalhes todas as informações importantes que acontecerem no sistema o BISLogger registrar todos os eventos relacionados a uma Thread em memória, e se antes do fim da Thread ocorrer o registro de alguma informação desejada (definida em configuração), como por exemplo uma exception, todo o LOG (incluindo msgs do tipo Debug, Info, etc.) será salvo em banco de dados e posteriormente enviado aos servidores do BISServer. Caso nada ocorra as informações serão descartadas sem que se ocupe espaço registrando informações desnecessárias. É possível configurar o Auto-Debugger para saber quais dados são importantes para registro, verifique a sessão de Configuração para saber como.

Relatórios O Auto-Debugger funciona independente das configurações de impressão das mensagens. Isto é, mesmo que as configurações não permitam que o BIS escreva no console o registro dos erros, o Auto-Debugger continuará registrando estas mensagens para reportar aos servidores.

BISValidationException Quando as exceptions são da classe BISValidationException o BISLogger não faz registro automático (exceto se configurado para isso) e ignora como se não tivessem ocorrido exceptions. Isso porque não trata-se de um erro, mas sim de alguma falha de validação nos dados recebidos para processamento. Em outras palavras, as exceptions de validação não são tratadas junto com as demais exceptions do sistema. Para registrar toda e qualquer exception de Validation, o BISLogger deve ser explicitamente configurado.

Nível de Registro das Mensagens O Auto-Debugger funciona independente das configurações de impressão das mensagens. Isto é, mesmo que as configurações não permitam que o BIS escreva no console o registro dos erros, o Auto-Debugger continuará registrando estas mensagens para reportar aos servidores.

Configuração BISLogger

O BISLogger deve ser configurado no servidor, através das propriedades de sistema abaixo:

Propriedades de Configurações BISLogger
Propriedade	Efeito
br.com.biserp.biscore.bislogger.systemout.info	True para jogar no System.out todas as informações que forem logadas. False ignora.
br.com.biserp.biscore.bislogger.systemout.warn	True para jogar no System.out todos os alertas que forem logados. False ignora.
br.com.biserp.biscore.bislogger.systemout.error	True para jogar no System.out todos os erros que forem logados. False ignora.
br.com.biserp.biscore.bislogger.systemout.debug	True para jogar no System.out todos os debugs que forem logados. False ignora.
br.com.biserp.biscore.bislogger.systemout.report	True para jogar no System.out todos os reports que forem logados. False ignora.
br.com.biserp.biscore.bislogger.systemout.validations	True para jogar no System.out todas as exceções de validação que forem logados. False ignora.
br.com.biserp.biscore.bislogger.systemout.exceptions	True para jogar no System.out todas as exceções (exceto de validações) que forem logados. False ignora.
br.com.biserp.biscore.bislogger.systemout.vos	True para jogar no System.out todos os VOs que forem logados. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.info	True para enviar para o BISServer todas as informações que forem logadas. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.warn	True para enviar para o BISServer todos os alertas que forem logados. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.error	True para enviar para o BISServer todos os erros que forem logados. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.debug	True para enviar para o BISServer todos os debugs que forem logados. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.report	True para enviar para o BISServer todos os reports que forem logados. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.validations	True para enviar para o BISServer todas as exceções de validação que forem logados. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.exceptions	True para enviar para o BISServer todas as exceções (exceto de validações) que forem logados. False ignora.
br.com.biserp.biscore.bislogger.autodebugger.vos	True para enviar para o BISServer todos os VOs que forem logados. False ignora.

Configurações Auto-Debugger Se o Auto-Debugger estiver configurado para enviar apenas mensagens do tipo exception, significa que ele enviará apenas Logs em que tenham ocorrido registro de exceptions, porém o Log completo será enviado, com o registro dos debugs, infos, warns, e tudo mais. Não apenas a informação definida para enviar. Em outras palavras, as configurações do auto-debugger indicam quais mensagens devem aparecer no log para que ele seja importante o suficiente a ponto de ser enviado para o BISServer.

Ownership

O BISLogger tem na ideia não gerar um único arquivo de log com tudo o que acontece, mas sim separar as informações por processamento, ou acionamento, de forma que as informações não se misturem já que se trata se uma plataforma multiusuário.

O sistema de ownership do relatório de erro foi criado para ajudar a resolver alguns problemas que impedem esse funcionamento adequadamente.

Os problemas conhecidos:

1. pool de thread - para otimizar a performance, o servidor de aplicações trabalha com pools de threads que já permanecem abertas para ganhar tempo durante as chamadas de usuários. Isso ocorre por exemplo para conexões com o banco de dados, para requisições fachada, requisições http, etc. Como uma das interfaces do BIS é web, as requisições são sempre tratadas pelas mesmas threads, e como estas nunca morrem o BISLogger não consegue perceber a hora de finalizar o relatório.

   A solução encontrada para esse problema é "fácil", forçar que no fim dos métodos de "entrada" da aplicação force a finalização do relatório de Log. Por exemplo, recebemos uma requisição http no nosso servlet, tratamos a requisição e no final fazemos a finalização no BISLogger. O que nos leva ao problema 2:

2. multiplos pontos de entrada do sistema - O BIS tem múltiplos pontos de entrada no sistema, e muitos usados pelo próprio BIS. Por exemplo, podemos ter uma requisição http na camada de presentation, esta para obter os dados aciona o Fachada do CRUD para obter os dados necessários, já o CRUD precisa acionar a fachada de outro BISPlugin ou do BISCore pra obter outros dados necessários. Em outro momento, podemos ter simplesmente uma chamada diretamente na fachada, sem passar pelo http ou por fachadas de outros BISPlugins.

   A solução para os dois problemas é definir por onde foi que a entrada ocorreu. Assim é o sistema do Ownership.

No Servlet, nas Fachadas e em qualquer outro ponto de entrada do sistema devemos registrar no BISLogger que aquela classe é o 'dono' do log! E só ele poderá finaliza-lo. Evitando assim que outros pontos de entrada consigam finaliza-lo. Em resumo, os pontos de entrada devem ter um código similar ao abaixo para tomar 'posse' do relatório de log:

Tomando Posse do Relatório de Log Long ownerkey = BISLogger.takeOwnership(); try { //Todo o código da aplicação normalmente } finally { BISLogger.finishOwner(ownerkey); }

Com isso o BISLogger distribuirá chaves para os interessados em obter o ownership do log, mas somente o primeiro que tomar posse poderá finaliza-lo.

Só para mesma thread! Note que o BISLogger só consegue perceber quem é o dono do log de acordo com a thread que solicitou o ownership. Se o sistema bifurcar em threads, o BISLogger fará novos relatórios para cada nova threads. Como o BISLogger não tem um sistema de redirecionar logs de uma thread para outra, (mesmo porque isso misturaria os logs das várias threads) é aconselhável que se crie se crie "chaves" e se registre nos relatórios das Threads, para que se for necessário o desenvolvedor possa identificar o relatório da outra Thread. Por exemplo, no fim da thread que lançará as novas threads registramos "Thread Bifurcando ID: <qualquer id randomico>", e nas Novas Threads registramos "Thread bifurcada! Continuação do ID: <mesmo id randomico do anterior>".