logging Disable Axis log4j em jboss

Question

Eu tenho pequena aplicação que está a fazer upload de fotos para um outro site via webservice. Meu problema atual é que Axis está registrando a mensagem inteira xml (incluindo os dados binários da imagem!) Via STDOUT e eu não consigo descobrir, como desativá-lo.

O meu log4j configurações para jboss (jboss-log4j.xml) inclui um appender para loggings normais STDOUT Info, e eu tentei eixo disable com diferentes configurações de categoria:

<appender name="STDLOG" class="org.jboss.logging.appender.RollingFileAppender">
  <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
  <param name="File" value="${jboss.server.log.dir}/myapplication.log"/>
  <param name="Append" value="true"/>
    <param name="MaxFileSize" value="5MB"/>
    <param name="MaxBackupIndex" value="10"/>

    <layout class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern" value="%d %-5p [%c] (%t) %m%n"/>
  </layout>
</appender>

usando essa configuração para STDOUT:

<category name="STDOUT">
  <priority value="DEBUG"/>
  <appender-ref ref="STDLOG"/>
</category>

Eu tentei essas configurações categoria sem qualquer alteração no resultado:

<category name="log4j.logger.org.apache.axis" additivity="false">
  <priority value="ERROR"/>
</category>

<category name="org.apache.axis">
  <priority value="ERROR"/>
</category>

Alguns log amostra olhares saída como esta:

2009-08-07 10:29:43,911 INFO  [STDOUT] (http-127.0.0.1-8080-1) =======================================================
= Elapsed: 2190 milliseconds
= In message: <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <addVehicleImage xmlns="urn:VMgrWebService">
   <id xmlns="">APP-T4QKR3U</id>
   <idType xmlns="">chiffre</idType>
   <data xmlns="">9j4AAQSkZJRgABAQAAAQABAAD2wBDAAUDBAQEAwUEBAQFB
     QUGBww0TDMnrXAfKlLjnNJZcciiAOtqk9NG99qhZJKuyYq5k3G
     8P2bVSOpT7rVddRP2Z/yqidRuMMKaO2CXRQNWP2jfOo4S4Bo3W
   removed rest of image data...
     IBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGe1UqaZJJy0jSHPGQ
2009-08-07 10:29:43,927 INFO  [STDOUT] (http-127.0.0.1-8080-1) Upload result: true for image mypicture.JPG  

Atualizar Eu verifiquei o eixo 1.4.jar e há um arquivo chamado simplelog.properties :

# Logging detail level,
# Must be one of ("trace", "debug", "info", "warn", "error", or "fatal").
org.apache.commons.logging.simplelog.defaultlog=info

A definição desse a erro dentro do frasco, ou como uma categoria em jboss-log4j.xml não ajuda em nada.

Qualquer pessoa alguma idéia de como eu posso desligar o registro Axis ou, pelo menos, set-lo ao nível de erro?

Felicidades
Frank

Answer 1

Ok, depois de tentar encontrar uma solução melhor, a única maneira real era para verificar o código legado velho e virar todas as chamadas System.out em declarações madeireiras reais (muito melhor de qualquer maneira), e depois simplesmente filtrar os restantes mensagens STDOUT em um arquivo de log diferente.

Uma das principais razões parece ser a própria Jboss. Este discussão da lista de discussão eixo2 explica porque: Ahh, mas você não mencionou que você está usando jboss! É muito bonito forças você use sua configuração log4 pai. Ignorar o registro eixo2 neste caso, e veja:

~ / jboss / server / default / conf / log4j.xml

Lá você tem que limitar as categorias. Por exemplo, você tem:

<category name="org.apache">
  <priority value="INFO"/>
</category>

Você pode deixar que, como é e apenas obter seus registros de server.log.

Eu tentei definindo a categoria, sem sucesso. Suponho que isso é por causa de diferenças entre eixos e axis2. Assim, a única solução esquerda era ir a boa codificação caminho e simplesmente não usar STDOUT no seu próprio código; -)

Answer 2

Este pode ser um pouco no final do dia, mas o problema não parece ser que a exploração madeireira em si é feito em Axis (via System.out e Commons Logging), mas sim que o LogHandler está presente na cadeia de manipulador. É assim que o tempo decorrido está sendo registrado.

Você pode desativar esse manipulador do Axis arquivo de configuração ( s.) - server-config.wsdd e / ou cliente-config.wsdd, dependendo se você estiver usando o Eixo como um servidor ou um cliente

A razão pela qual você está vendo mensagens no seu console é provavelmente devido ao LogHandler.writeToConsole propriedade sendo definida como True. Se você definir LogHandler.writeToConsole como falsa, ele deve escrever em um arquivo como definido pela propriedade LogHandler.fileName. Por padrão, o nome do arquivo é axis.log.

Answer 3

Primeiro, você vai querer verificar se a configuração do log4j é realmente o que está sendo lido - Lembro-me que no passado, pelo menos um frasco eixo (acho que pode ter sido axis-ant.jar) era culpado de empacotar seu próprio log4j.properties. Pode ser que log4j está lendo um arquivo de configuração diferente do seu, fazendo seus esforços para ajustar o sentido de configuração!

Você pode ativar o sistema propriedades -Dlog4j.debug ter impressão log4j para a norma que arquivo de configuração está sendo lido. Se necessário, você pode usar -Dlog4j.configuration=<file> para apontar para seu próprio arquivo.

Além disso, eu não acho que isso está causando problemas, mas por que você está definindo aditividade para false?

Answer 4

O problema é que o Eixo não está usando Log4j para registrar essa mensagem, então tentar alterar o nível de log log4j em que a classe não é relevante. Axis está usando um System.out.println.

A única coisa que posso pensar (o que não é muito bom dado os efeitos colaterais) é transformar o STDOUT fazer logoff completamente. definindo provavelmente a prioridade para fora vai fazer.

A única solução real é para corrigir Axis e corrigir o código para não bombear o xml para System.out mas sim usar o mecanismo de registro em vez -. Então você pode controlá-lo

Answer 5

É muito importante saber qual arquivo log4j.properties ou log4j.xml está sendo lido. e como Matt apontou, esta é crucial para saber por que seus esforços de ajustes não estão funcionando.