자체 제작 래퍼 뒤에 log4j를 사용하고 있습니다. 우리는 지금 훨씬 더 많은 기능을 사용할 계획입니다.
로그 백으로 업데이트해야합니까?
(SLF4J와 같은 외관이 아닌 프레임 워크를 의미합니다)
답변
로그 백은 기본적으로 SLF4J API를 구현합니다. 이는 로그 백을 사용하는 경우 실제로 SLF4J API를 사용하고 있음을 의미합니다. 이론적으로 로그 백 API의 내부를 로깅에 직접 사용할 수는 있지만 권장하지는 않습니다. 로거에 대한 모든 로그 백 문서 및 예제는 SLF4J API로 작성되었습니다.
따라서 로그 백을 사용하면 실제로 SLF4J를 사용하게되며 어떤 이유로 든 log4j로 다시 전환하려면 몇 분 안에 slf4j-log4j12.jar를 클래스 경로에 놓아서 몇 분 안에 그렇게 할 수 있습니다.
logback에서 log4j로 마이그레이션 할 때 특정 부분, 특히 logback.xml 구성 파일에 포함 된 부분 은 여전히 log4j에 해당하는 부분 (예 : log4j.properties) 으로 마이그레이션해야합니다 . 다른 방향으로 마이그레이션 할 때 log4j 구성 (예 : log4j.properties )을 해당 로그 백으로 변환해야합니다. 이를 위한 온라인 도구 가 있습니다. 구성 파일 마이그레이션과 관련된 작업량은 모든 소프트웨어 소스 코드 및 해당 종속성 전체에 전파되는 로거 호출을 마이그레이션하는 데 필요한 작업보다 훨씬 적습니다.
답변
당신은해야합니까? 예 .
왜? Log4J 는 본질적으로 Logback에 의해 사용되지 않습니다 .
긴급한가요? 아마.
고통스럽지 않습니까? 아마,하지만 당신의 로깅 문에 따라 달라질 수 있습니다.
LogBack (또는 SLF4J)을 최대한 활용하려면 적절한 로깅 문 을 작성해야 합니다 . 이렇게하면 평가 지연으로 인해 코드가 빨라지고 경비원을 피할 수 있으므로 코드 줄이 줄어드는 등의 이점을 얻을 수 있습니다.
마지막으로 SLF4J를 적극 권장합니다. (왜 자신의 외관으로 바퀴를 재생성합니까?)
답변
로깅 세계에는 Facades (Apache Commons Logging, slf4j 또는 심지어 Log4j 2.0 API)와 구현 (Log4j 1 + 2, java.util.logging, TinyLog, Logback)이 있습니다.
기본적으로 자체 제작 래퍼를 slf4j IF로 교체해야하며 어떤 이유로 든 만족하지 않는 경우에만 사용해야합니다. Apache Commons Logging은 실제로 최신 API를 제공하지 않지만 slf4j 및 새로운 Log4j 2 외관은이를 제공합니다. 상당히 많은 앱이 slf4j를 래퍼로 사용한다는 점을 감안할 때 그것을 사용하는 것이 합리적 일 수 있습니다.
slf4j는 slf4j 문서의 다음 예제와 같이 많은 훌륭한 API 설탕을 제공합니다.
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
변수 대체입니다. 이것은 Log4j 2에서도 지원됩니다.
그러나 slf4j는 로그 백을 유지 관리하는 QOS가 개발했음을 알아야합니다. Log4j 2.0은 Apache Software Foundation에서 구워졌습니다. 지난 3 년 동안 활기차고 활동적인 커뮤니티가 다시 성장했습니다. Apache Software Foundation에서 모든 보증을 제공하므로 오픈 소스에 만족한다면 Log4j 2를 직접 사용하기 위해 slf4j를 사용하는 것이 좋습니다.
참고 :
과거에는 log4j 1이 Logback이 진행되는 동안 적극적으로 유지되지 않았습니다. 그러나 오늘날 상황은 다릅니다. Log4j 2는 거의 정기적으로 활발하게 유지 보수 및 릴리스됩니다. 또한 많은 최신 기능이 포함되어 있으며 Logim보다 몇 가지 기능을 향상시킵니다. 이것은 때때로 맛의 문제 일 뿐이므로 자신의 결론을 이끌어 내야합니다.
Log4j 2.0의 새로운 기능에 대한 간단한 개요를 작성했습니다 : http://www.grobmeier.de/the-new-log4j-2-0-05122012.html
읽을 때 Log4j 2는 Logback뿐만 아니라 다른 로깅 프레임 워크에서도 영감을 얻었습니다. 그러나 코드베이스는 다릅니다. Log4j 1과 거의 아무것도 공유하지 않으며 Logback과 0을 공유합니다. 예를 들어 Log4j 2와 같은 일부 개선 사항은 후드 아래의 문자열 대신 바이트 스트림으로 작동합니다. 또한 재구성하는 동안 이벤트를 풀지 않습니다.
Log4j 2는 내가 알고있는 다른 프레임 워크보다 빠른 속도로 로깅 할 수 있습니다 : http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
그리고 여전히 사용자 커뮤니티는 Logbacks보다 훨씬 더 큰 것 같습니다 : http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
가장 좋은 아이디어는 달성하고자하는 것에 가장 적합한 로깅 프레임 워크를 선택하는 것입니다. 프로덕션 환경에서 로깅을 비활성화하고 내 앱에서 기본 로깅을 수행하면 전체 프레임 워크를 전환하지 않습니다. 그러나 로깅을 조금만 더하면 프레임 워크와 해당 개발자가 제공하는 기능을 살펴보십시오. QOS를 통해 Logback에 대한 상업적 지원을 받고 있지만 현재 Log4j 2에 대한 상업적 지원은 없습니다. 반면에 감사 로깅을 수행해야하고 비동기 어 펜더가 제공하는 고성능이 필요한 경우에는 다음과 같은 의미가 있습니다. log4j를 확인하십시오 .2.
모든 편안함에도 불구하고 외관은 항상 약간의 성능을 발휘합니다. 그것은 당신에게 전혀 영향을 미치지 않을 수도 있지만, 자원이 부족한 경우 가능한 모든 것을 저장해야 할 수도 있습니다.
요구 사항을 더 잘 알지 못하면 권장 사항을 제시하는 것이 거의 불가능합니다. 단지 : 많은 사람들이 전환했기 때문에 전환하지 마십시오. 가치가 있기 때문에 전환하십시오. 그리고 log4j가 죽었다는 주장은 더 이상 계산되지 않습니다. 살아 있고 덥습니다.
면책 조항 : 저는 현재 Apache Logging Services 부사장이며 log4j에도 참여하고 있습니다.
답변
귀하의 질문에 정확하게 대답하지는 않지만 자체 제작 래퍼에서 벗어날 수 있다면 Hibernate가 (일반 로깅 대신) 전환 한 SLF4J (Simple Logging Facade for Java )가 있습니다.
SLF4J는 Jakarta Commons Logging (JCL)에서 관찰 된 클래스 로더 문제 나 메모리 누수로 고통받지 않습니다.
SLF4J는 JDK 로깅, log4j 및 로그 백을 지원합니다. 따라서 시간이 맞으면 log4j에서 logback으로 전환하는 것이 매우 쉽습니다.
편집 : 내가 명확하게하지 않은 사과. log4j 또는 logback 중에서 어려운 선택을하지 않아도되도록 SLF4J를 사용하는 것이 좋습니다.
답변
당신의 결정은
- 이러한 “더 많은 기능”에 대한 실제 요구; 과
- 변경 구현 예상 비용
API가 “더 새롭고, 더 밝고, 더 좋다”는 이유만으로 API를 변경하려는 충동에 저항해야합니다. 나는 “깨지지 않으면 걷지 말아라”라는 정책을 따릅니다.
애플리케이션에 매우 정교한 로깅 프레임 워크가 필요한 경우 이유를 고려할 수 있습니다.
답변
성숙 된 프로젝트 나 심지어 개발 단계에 깊은 프로젝트는 아마도 그러한 업그레이드로부터 얻는 것보다 더 느슨 할 것입니다 (IMHO). 로그 백은 확실히 여러 지점에서 훨씬 발전하지만 작업 시스템에서 완전히 교체 할 수있는 정도는 아닙니다. 나는 확실히 새로운 개발을 위해 로그 백을 고려할 것이지만, 기존의 log4j는 이미 최종 사용자를 만나고 만난 모든 것에 충분하고 성숙합니다. 이것은 매우 주관적이며, 비용은 본인이 부담해야합니다.
답변
