Logger Classe

Definição

[Android.Runtime.Register("java/util/logging/Logger", DoNotGenerateAcw=true)]
public class Logger : Java.Lang.Object

[<Android.Runtime.Register("java/util/logging/Logger", DoNotGenerateAcw=true)>]
type Logger = class
    inherit Object

Herança

Object

JavaObject

Object

Logger

Atributos

RegisterAttribute

Comentários

Um objeto Logger é usado para registrar mensagens para um componente específico do sistema ou do aplicativo. Os agentes normalmente são nomeados, usando um namespace hierárquico separado por pontos. Os nomes de agente podem ser cadeias de caracteres arbitrárias, mas normalmente devem ser baseados no nome do pacote ou no nome da classe do componente registrado, como java.net ou javax.swing. Além disso, é possível criar agentes "anônimos" que não são armazenados no namespace do agente.

Os objetos do agente podem ser obtidos por chamadas em um dos métodos de fábrica getLogger. Eles criarão um novo agente ou retornarão um agente existente adequado. É importante observar que o agente retornado por um dos métodos de getLogger fábrica pode ser o lixo coletado a qualquer momento se uma referência forte ao agente não for mantida.

As mensagens de registro em log serão encaminhadas para objetos do Manipulador registrados, que podem encaminhar as mensagens para uma variedade de destinos, incluindo consoles, arquivos, logs do sistema operacional etc.

Cada agente mantém o controle de um agente "pai", que é seu ancestral existente mais próximo no namespace do agente.

Cada agente tem um "Nível" associado a ele. Isso reflete um nível mínimo com o qual esse agente se preocupa. Se o nível de um agente estiver definido como null, seu nível efetivo será herdado de seu pai, o que, por sua vez, pode obtê-lo recursivamente de seu pai e assim por diante na árvore.

O nível de log pode ser configurado com base nas propriedades do arquivo de configuração de log, conforme descrito na descrição da classe LogManager. No entanto, ele também pode ser alterado dinamicamente por chamadas no método Logger.setLevel. Se o nível de um agente for alterado, a alteração também poderá afetar os agentes filho, uma vez que qualquer agente filho que tenha null como nível herdará seu nível efetivo de seu pai.

Em cada chamada de log, o agente inicialmente executa uma verificação barata do nível de solicitação (por exemplo, SEVERE ou FINE) no nível de log efetivo do agente. Se o nível de solicitação for menor que o nível de log, a chamada de registro em log retornará imediatamente.

Depois de passar nesse teste inicial (barato), o Agente alocará um LogRecord para descrever a mensagem de registro em log. Em seguida, ele chamará um Filtro (se presente) para fazer uma verificação mais detalhada sobre se o registro deve ser publicado. Se isso for aprovado, ele publicará o LogRecord em seus Manipuladores de saída. Por padrão, os agentes também publicam nos Manipuladores de seus pais, recursivamente até a árvore.

Cada agente pode ter um ResourceBundle associado a ele. Pode ResourceBundle ser especificado pelo nome, usando o método de #getLogger(java.lang.String, java.lang.String) fábrica ou por valor – usando o #setResourceBundle(java.util.ResourceBundle) setResourceBundle método. Esse pacote será usado para localizar mensagens de registro em log. Se um agente não tiver seu próprio ResourceBundle nome ou de pacote de recursos, ele herdará o nome ou o ResourceBundle pacote de recursos de seu pai, recursivamente até a árvore.

A maioria dos métodos de saída do agente usa um argumento "msg". Esse argumento msg pode ser um valor bruto ou uma chave de localização. Durante a formatação, se o agente tiver (ou herdar) uma localização ResourceBundle e se tiver ResourceBundle um mapeamento para a cadeia de caracteres msg, a cadeia de caracteres msg será substituída pelo valor localizado. Caso contrário, a cadeia de caracteres msg original será usada. Normalmente, os formatadores usam a formatação de estilo java.text.MessageFormat para formatar parâmetros, portanto, por exemplo, uma cadeia de caracteres de formato "{0}{1}" formataria dois parâmetros como cadeias de caracteres.

Um conjunto de métodos, como alternativa, usa um "msgSupplier" em vez de um argumento "msg". Esses métodos assumem uma Supplier<String> função que é invocada para construir a mensagem de log desejada somente quando a mensagem realmente deve ser registrada com base no nível de log efetivo, eliminando assim a construção de mensagens desnecessárias. Por exemplo, se o desenvolvedor quiser registrar o status de integridade do sistema para diagnóstico, com a versão de aceitação de cadeia de caracteres, o código será semelhante a:

<code>

               class DiagnosisMessages {
                 static String systemHealthStatus() {
                   // collect system health information
                   ...
                 }
               }
               ...
               logger.log(Level.FINER, DiagnosisMessages.systemHealthStatus());
</code>

Com o código acima, o status de integridade é coletado desnecessariamente mesmo quando o nível de log FINER é desabilitado. Com a versão de aceitação de fornecedor como abaixo, o status só será coletado quando o nível de log FINER estiver habilitado.

<code>

               logger.log(Level.FINER, DiagnosisMessages::systemHealthStatus);
</code>

Ao procurar um ResourceBundle, o agente examinará primeiro se um pacote foi especificado usando #setResourceBundle(java.util.ResourceBundle) setResourceBundlee, em seguida, somente se um nome de pacote de recursos foi especificado por meio do #getLogger(java.lang.String, java.lang.String) getLogger método de fábrica. Se nenhum ResourceBundle ou nenhum nome de pacote de recursos for encontrado, ele usará o nome do pacote de recursos ou mais próximo ResourceBundle herdado de sua árvore pai.<br> Quando um ResourceBundle foi herdado ou especificado por meio do #setResourceBundle(java.util.ResourceBundle) setResourceBundle método, isso ResourceBundle será usado. Caso contrário, se o agente tiver ou herdado apenas um nome de pacote de recursos, esse nome do pacote de recursos será mapeado para um ResourceBundle objeto, usando a Localidade padrão no momento do registro em log. <br id="ResourceBundleMapping">Ao mapear nomes de pacote de recursos para ResourceBundle objetos, o agente primeiro tentará usar o carregador de classe de contexto java.lang.Thread#getContextClassLoader() do Thread para mapear o nome do pacote de recursos fornecido para um ResourceBundle. Se o carregador de classe de contexto de thread for null, ele tentará o carregador de classe do sistema java.lang.ClassLoader#getSystemClassLoader(). Se ainda ResourceBundle não for encontrado, ele usará o carregador de classe do primeiro chamador do #getLogger(java.lang.String, java.lang.String) getLogger método de fábrica.

A formatação (incluindo a localização) é responsabilidade do Manipulador de saída, que normalmente chamará um Formatador.

Observe que a formatação não precisa ocorrer de forma síncrona. Ele pode ser adiado até que um LogRecord seja realmente gravado em um coletor externo.

Os métodos de registro em log são agrupados em cinco categorias principais: <ul><li>

Há um conjunto de métodos de "log" que levam um nível de log, uma cadeia de caracteres de mensagem e, opcionalmente, alguns parâmetros para a cadeia de caracteres de mensagem. <li>

Há um conjunto de métodos "logp" (para "log preciso") que são como os métodos de "log", mas também usam um nome de classe de origem explícito e um nome de método. <li>

Há um conjunto de métodos "logrb" (para "log com pacote de recursos") que são como o método "logp", mas também usam um objeto de pacote de recursos explícito para uso na localização da mensagem de log. <li>

Há métodos de conveniência para rastrear entradas de método (os métodos "entering"), o método retorna (os métodos de "saída") e lançar exceções (os métodos de "lançamento"). <li>

Por fim, há um conjunto de métodos de conveniência para uso nos casos mais simples, quando um desenvolvedor simplesmente deseja registrar uma cadeia de caracteres simples em um determinado nível de log. Esses métodos são nomeados após os nomes de nível padrão ("grave", "aviso", "informações", etc.) e usam um único argumento, uma cadeia de caracteres de mensagem. </ul>

Para os métodos que não usam um nome de origem explícito e um nome de método, a estrutura de registro em log fará um "melhor esforço" para determinar qual classe e método chamados para o método de registro em log. No entanto, é importante perceber que essas informações inferidas automaticamente só podem ser aproximadas (ou podem até estar muito erradas!). As máquinas virtuais têm permissão para fazer otimizações abrangentes quando JITing e podem remover totalmente os quadros de pilha, tornando impossível localizar de forma confiável a classe de chamada e o método.

Todos os métodos no Agente são seguros para vários threads.

<b>Informações de subclasse:</b> Observe que uma classe LogManager pode fornecer sua própria implementação de agentes nomeados para qualquer ponto no namespace. Portanto, todas as subclasses do Agente (a menos que sejam implementadas em conjunto com uma nova classe LogManager) devem ter cuidado para obter uma instância do Agente da classe LogManager e devem delegar operações como "isLoggable" e "log(LogRecord)" para essa instância. Observe que, para interceptar toda a saída de log, as subclasses precisam substituir apenas o método log(LogRecord). Todos os outros métodos de registro em log são implementados como chamadas neste método log(LogRecord).

Adicionado em 1.4.

Java documentação para java.util.logging.Logger.

Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Android Open Source Project e usadas de acordo com os termos descritos na Licença de Atribuição Creative Commons 2.5.