2013-11-21 6 views
1

다음은 Tomcat 7 콘솔에서 나오는 로깅 명령문의 몇 가지 샘플입니다. 대부분은 열린 saml 또는 최대 절전 모드에서오고 있으며 나는 그 (것)들이 나오지 못하도록 막으려 고합니다. 나는 logback을 사용하고 있으며 루트 로거와 WARN 이상의 모든 로거를 가지고 있으며 특정 라이브러리가 INFO 및 DEBUG 레벨 문을 계속 로그 아웃하는 이유를 알 수 없습니다. 어떤 아이디어?예기치 않게 Tomcat DEBUG 로깅이 콘솔에서 나옴

14:40:45.360 [localhost-startStop-6] DEBUG org.opensaml.xml.XMLConfigurator - {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Username intialized and configuration cached 
14:40:45.360 [localhost-startStop-6] DEBUG org.opensaml.xml.XMLConfigurator - Initializing object provider {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken 
14:40:45.360 [localhost-startStop-6] DEBUG org.opensaml.xml.Configuration - Registering new builder, marshaller, and unmarshaller for {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken 
14:40:45.361 [localhost-startStop-6] DEBUG org.opensaml.xml.XMLConfigurator - {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken intialized and configuration cached 
14:40:45.361 [localhost-startStop-6] DEBUG org.opensaml.xml.XMLConfigurator - ObjectProviders load complete14:40:45.361 [localhost-startStop-6] DEBUG org.opensaml.xml.XMLConfigurator - Preparing to load IDAttributes 
14:40:45.361 [localhost-startStop-6] DEBUG org.opensaml.xml.XMLConfigurator - IDAttribute {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Id has been registered 
14:40:45.361 [localhost-startStop-6] DEBUG org.opensaml.xml.XMLConfigurator - IDAttributes load complete 
14:40:45.361 [localhost-startStop-6] DEBUG org.opensaml.DefaultBootstrap - Initializing SAML Artifact builder factories 

답변

0

모든 유용한 위에도 불구하고, 너무 그것을 알아 내기 위해 나에게 시간이 걸렸다 하이퍼 링크 및 참조. My config는 Spring Tools Suite에서 시작된 TcServer에서 실행되는 Tomcat 7 인스턴스입니다. 그러나 실마리가 주어졌습니다. logback은 실제로 (여전히) 범인이었습니다. slaven4j에서 순수 log4j 바인딩을 사용하기 위해 필자가 Maven 종속 계층에서 완전히 제거했지만 (물론 LogbackConfigListener는 다른 곳에서 볼 수 없었습니다) ... 하지만 maven을 강제로 삭제하는 것을 잊어 버렸고 logback jar 복사본이 war 아카이브가 만들어진 대상 하위 디렉토리에 여전히 존재했습니다. Suprinsingly 충분히, 전쟁 에서이 로그백 항아리의 존재는 DEBUG 모드로 서버 로그인을 속일 정도로 충분했습니다. Project clean - maven clean - rebuild, maven package를 다시 실행 한 다음 deploy : 서버 로그를 콘솔에서 깨끗하게 처리하고, 마지막으로 src/main/resources/log4j.xml 설정을 준수합니다. 단 하나의 로그 설정 파일은 변경하지 않았습니다.

여분의 시간을 절약하기위한 추가 팁 : slf4j-log4j에 대한 종속성을 엄격하게 재구성하면서 log4j 버전 1.2.17 및 1.2.15와 JRE1.6 이상을 사용하여 Maven 종속성 누락과 관련된 다른 문제를 방지하십시오. JMS, JDMK 및 JMX ... :-)

알림 : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009731

: STS에서 시작 TcServer/바람둥이에 대한 로깅 설정을 사용자 정의