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

새 프로젝트는 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도 사용할 수 있습니다.

---

Logback more Java EE aware:
in general (from code to documentation) it’s keeping in mind containers – how multiple apps coexist, how class loaders implemented etc. Contexts for loggers, JNDI, JMX configuration included etc.

from developer prospective almost same, Logback adds Parameterized logging (no need to use if(logger.isDebugEnabled()) to avoid string concatenation overhead )

Log4j – only giant plus is old JVM support, small (IMO) NDC (Logback only MDC), some extensions. For example I wrote extension for configureAndWatch for Log4j, no such thing for Logback

---

the original log4j and logback were designed and implemented by the same guy.

several open source tools have used SLF4J. I don't see any significant deficiencies in this tool. So unless you have a lot extensions to log4j in your codebase, I would go ahead with logback.

---

I would think that your decision should come down to the same one it would if you were deciding between using log4j or Jakarta Commons Logging - are you developing a library which will be included in other applications? If so, then it doesn't seem fair to force users of your library to also use your logging library of choice.

If the answer is no, I would just go with what is simpler to add and what you are more comfortable with. Sounds like logback is just as extensible and reliable as log4j, so if you're comfortable using it, go ahead.

---

I'm not familiar with SLF4J, and I've only taken a brief look at logback, but two things come to mind.

First, why are you excluding a tool from examination? I think it's important to keep an open mind and examine all possibilities to choose the best one.

Second, I think that in some projects one tool is a better than another tool, and the opposite might be true in a different project. I don't think that one tool is always better than another tool. There is, after all, no silver bullet.

To answer your question - Yes and no. It depends on the project, and how familiar the team is with one tool. I wouldn't say "don't use log4j" if the entire team is very comfortable with it, it meets all the needs, and logback doesn't offer anything that we need to complete the task.

참고URL : https://stackoverflow.com/questions/178836/should-new-projects-use-logback-instead-of-log4j