새 프로젝트는 log4j 대신 logback을 사용해야합니까? [닫은]

새 프로젝트는 로깅 프레임 워크로 log4j 대신 logback을 사용해야합니까?

또는 다른 말로 : '로그 백이 log4j보다 낫습니까 (로그 백의 SLF4J-'기능 '을 옆에 남겨둔다)?'

로깅에는 SLF4J + Logback을 사용해야합니다.

매개 변수화 된 메시지 및 (commons-logging과 달리) Mapped Diagnostic Context (MDC, javadoc , documentation ) 와 같은 깔끔한 기능을 제공합니다 .

SLF4J를 사용하면 로깅 백엔드를 매우 우아한 방식으로 교환 할 수 있습니다.

또한 SLF4J 는 다른 로깅 프레임 워크를 사용할 실제 SLF4J 구현에 연결 하는 것을 지원 하므로 타사 소프트웨어의 로깅 이벤트가 통합 로그에 표시됩니다. 단, 연결될 수없는 java.util.logging 다른 로깅 프레임 워크와 동일한 방식입니다.

Bridging jul은 SLF4JBridgeHandler 의 javadocs 에 설명되어 있습니다.

저는 여러 프로젝트에서 SLF4J + Logback 조합을 사용하여 매우 좋은 경험을했으며 LOG4J 개발이 거의 중단되었습니다.

SLF4J에는 다음과 같은 단점이 있습니다.

• Java <1.5와의 호환성을 유지하기 위해 varargs를 지원하지 않습니다.
• 매개 변수화 된 메시지와 예외를 동시에 사용하는 것은 지원하지 않습니다.
• LOG4J 에있는 중첩 진단 컨텍스트 (NDC, javadoc )에 대한 지원은 포함되지 않습니다 .

작성자 (Logback 및 Log4j 모두)는 http://logback.qos.ch/reasonsToSwitch.html 에서 변경해야하는 이유 목록을 가지고 있습니다 .

여기 저에게 튀어 나온 몇 가지가 있습니다.

• 더 빠른 구현

  log4j에 대한 이전 작업을 기반으로 로그 백 내부는 특정 중요 실행 경로에서 약 10 배 더 빠르게 수행되도록 다시 작성되었습니다. 로그 백 구성 요소가 더 빠를뿐만 아니라 메모리 공간도 더 작습니다.

• 구성 파일 자동 재로드

  Logback-classic은 수정시 구성 파일을 자동으로 다시로드 할 수 있습니다. 스캔 프로세스는 스캔을위한 별도의 스레드를 생성하지 않기 때문에 빠르고 안전합니다. 이러한 기술적 미묘함은 로그 백이 애플리케이션 서버 내에서 그리고보다 일반적으로 JEE 환경 내에서 잘 재생되도록합니다.

• 패키징 데이터로 추적 스택

  로그 백이 예외를 인쇄하면 스택 추적에 패키징 데이터가 포함됩니다. 다음은 logback-demo 웹 애플리케이션에 의해 생성 된 샘플 스택 추적입니다.

  14 : 28 : 48.835 [btpool0-7] 정보 cqldemo.prime.PrimeAction-99는 유효한 값이 아닙니다. java.lang.Exception : 99는
  ch.qos.logback.demo.prime.PrimeAction.execute (PrimeAction.java에서 유효하지 않습니다 . : 28) [classes / : na] at org.apache.struts.action.RequestProcessor.processActionPerform (RequestProcessor.java:431) [struts-1.2.9.jar : 1.2.9] at org.apache.struts.action. RequestProcessor.process (RequestProcessor.java:236) [struts-1.2.9.jar : 1.2.9] at org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:432) [struts-1.2.9.jar : 1.2.9] at javax.servlet.http.HttpServlet.service (HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar : 6.1.12]
  at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:502) [jetty-6.1.12.jar : 6.1.12] at ch.qos.logback.demo.UserServletFilter.doFilter (UserServletFilter.java:44 ) [classes / : na] at org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter (ServletHandler.java:1115) [jetty-6.1.12.jar : 6.1.12] at org.mortbay.jetty.servlet. ServletHandler.handle (ServletHandler.java:361) [jetty-6.1.12.jar : 6.1.12] at org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:417) [jetty-6.1.12.jar : 6.1.12] at org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:230) [jetty-6.1.12.jar : 6.1.12]

  위에서 살펴보면 응용 프로그램이 Struts 버전 1.2.9를 사용하고 있으며 jetty 버전 6.1.12에서 배포되었음을 알 수 있습니다. 따라서 스택 추적은 예외에 관련된 클래스뿐만 아니라 이들이 속한 패키지 및 패키지 버전에 대해 독자에게 신속하게 알려줍니다. 고객이 스택 추적을 보낼 때 개발자는 더 이상 사용중인 패키지 버전에 대한 정보를 보내달라고 요청할 필요가 없습니다. 정보는 스택 추적의 일부가됩니다. 자세한 내용은 "% xThrowable"변환 단어를 참조하십시오.

  이 기능은 일부 사용자가 자신의 IDE의 기능이라고 잘못 생각할 때 매우 유용 할 수 있습니다.

• 오래된 로그 아카이브 자동 제거

  TimeBasedRollingPolicy 또는 SizeAndTimeBasedFNATP의 maxHistory 속성을 설정하여 보관 된 파일의 최대 수를 제어 할 수 있습니다. 롤링 정책에서 월간 롤오버를 요구하고 1 년치의 로그를 유지하려면 maxHistory 속성을 12로 설정하기 만하면됩니다. 12 개월이 지난 아카이브 된 로그 파일은 자동으로 제거됩니다.

거기에 편견이있을 수 있지만, 같은 사람이 두 프레임 워크를 모두 작성했으며 Log4j보다 Logback을 사용한다고 말하면 들어 볼 가치가있을 것입니다.

모든 경우에 로깅에 slf4j를 사용합니다. 이를 통해 코드 시간 대신 배포 시간에 사용할 실제 로깅 백엔드를 선택할 수 있습니다.

이것은 나에게 매우 귀중한 것으로 입증되었습니다. 이전 JVM에서 log4j를 사용하고 1.5 이상의 JVM에서 logback을 사용할 수 있으며 필요한 경우 java.util.logging도 사용할 수 있습니다.

Java EE를 더 많이 인식하는 Logback :
일반적으로 (코드에서 문서까지) 컨테이너를 염두에 둡니다. 여러 앱이 공존하는 방식, 클래스 로더가 구현 된 방식 등. 로거 용 컨텍스트, JNDI, JMX 구성 포함 등.

개발자가 거의 같은 관점에서 Logback은 매개 변수화 된 로깅을 추가합니다 (문자열 연결 오버 헤드를 피하기 위해 if (logger.isDebugEnabled ())를 사용할 필요 없음).

Log4j – 거대 플러스는 구형 JVM 지원, 소형 (IMO) NDC (Logback 전용 MDC), 일부 확장입니다. 예를 들어 Log4j에 대한 configureAndWatch에 대한 확장을 작성했지만 Logback에는 그런 것이 없습니다.

원래의 log4j와 logback은 같은 사람이 설계하고 구현했습니다.

여러 오픈 소스 도구가 SLF4J를 사용했습니다. 이 도구에는 심각한 결함이 없습니다. 따라서 코드베이스에 log4j에 대한 확장이 많지 않으면 logback으로 진행할 것입니다.

log4j 또는 Jakarta Commons Logging 중 하나를 사용할 것인지 결정할 때와 같은 결정을 내려야한다고 생각합니다. 다른 응용 프로그램에 포함될 라이브러리를 개발하고 있습니까? 그렇다면 라이브러리 사용자가 선택한 로깅 라이브러리도 사용하도록 강요하는 것은 공정하지 않은 것 같습니다.

대답이 '아니요'인 경우 추가하기가 더 간단하고 더 편한 것을 선택하겠습니다. logback은 log4j만큼 확장 가능하고 신뢰할 수있는 것처럼 들리므로 사용하기에 익숙하다면 계속 진행하십시오.

저는 SLF4J에 익숙하지 않고 로그 백에 대해 간략히 살펴 봤지만 두 가지가 떠 오릅니다.

첫째, 검사에서 도구를 제외하는 이유는 무엇입니까? 나는 열린 마음을 유지하고 최선의 선택을 위해 모든 가능성을 검토하는 것이 중요하다고 생각합니다.

둘째, 어떤 프로젝트에서는 하나의 도구가 다른 도구보다 낫고 다른 프로젝트에서는 그 반대가 사실 일 수 있다고 생각합니다. 한 도구가 항상 다른 도구보다 낫다고 생각하지 않습니다. 결국 은색 총알은 없습니다 .

귀하의 질문에 답하려면-예 및 아니오. 프로젝트와 팀이 하나의 도구에 얼마나 익숙한 지에 따라 다릅니다. 전체 팀이 매우 편안하고 모든 요구 사항을 충족하며 로그 백이 작업을 완료하는 데 필요한 것을 제공하지 않는다면 "log4j를 사용하지 마십시오"라고 말하지 않을 것입니다.