log4j2에 slf4j를 사용할 가치가 있습니까?

log4j2에 slf4j를 사용할 가치가 있습니까?

log4j2에서는 slf4j를 사용할지 여부를 결정할 수 없습니다.온라인 게시물을 보면 성능 저하가 없을 것 같지만 꼭 필요한가요?

또, 다음의 포인트는 log4j2에 유리하게 되어 있습니다.

• SLF4J는 응용 프로그램에 강제로 문자열을 기록합니다.Log4j 2 API는 텍스트를 기록할 경우 CharSequence 로깅을 지원하지만 모든 개체를 있는 그대로 로깅할 수도 있습니다.
• Log4j 2 API는 메시지 객체 로깅, Java 8 lambda 표현식 및 가비지 프리 로깅을 지원합니다(Vararg 배열 작성 및 CharSequence 객체 로깅 시 문자열 작성 방지).

계속하세요: slf4j가 아닌 log4j2 API로 프로그래밍합니다.

안전합니다. Log4j2 API는 slf4j와 동일한 보증을 제공합니다.

Log4j2 자체가 API와 구현 모듈로 분리되었기 때문에 SLF4J를 사용하는 것은 의미가 없습니다.

네, 옵션을 열어두는 것이 엔지니어링의 좋은 방법입니다.나중에 다른 로깅 구현으로 변경할 수 있습니다.

지난 10여 년 동안 어플리케이션에서 이러한 유연성을 구축하면 SLF4J와 같은 래퍼 API를 사용해야 했습니다.그러나 이 유연성이 무료로 제공되는 것은 아닙니다.이 접근방식의 단점은 어플리케이션이 기본 로깅 라이브러리의 풍부한 기능 세트를 사용할 수 없다는 것입니다.

Log4j2는 애플리케이션을 최소 공통 분모로 제한할 필요가 없는 솔루션을 제공합니다.

배출 밸브: log4j-to-slf4j

Log4j2에는log4j-to-slf4j브리지 모듈Log4j2 API에 대해 코드화된 애플리케이션은 언제든지 slf4j 준거 구현으로 백업 구현을 전환할 수 있습니다.

질문에서 설명한 바와 같이 Log4j2 API를 직접 사용하면 slf4j와 같은 래퍼 API를 사용하는 경우와 비교하여 더 많은 기능을 제공하고 몇 가지 비기능적인 이점이 있습니다.

• 메시지 API
• 게으른 벌목을 위한 람다
• 문자열이 아닌 임의의 개체 기록
• 가비지 프리: 가능한 경우 변수 작성이나 문자열 작성을 피합니다.
• 닫힘Thread Context는 사용자가 항목을 완료하면 자동으로 MDC에서 항목을 삭제합니다.

(자세한 내용은 SLF4J에서 사용할 수 없는10 Log4j2 API 기능을 참조해 주세요).

애플리케이션은 Log4j2 API의 풍부한 기능을 네이티브 Log4j2 코어 구현에 얽매이지 않고 안전하게 사용할 수 있습니다.

SLF4J는 여전히 사용자의 안전밸브입니다.그것은 단지 당신의 애플리케이션이 SLF4J API에 대해 더 이상 코드화해야 한다는 것을 의미하지 않습니다.

---

공개:Log4j2에 기고하고 있습니다.

---

업데이트: Log4j2 API에 프로그래밍을 하면 "facement for passide"가 도입되는 혼란이 있는 것 같습니다.이 점에서는 Log4j2 API와 SLF4J의 차이는 없습니다.

두 API 모두 네이티브 구현을 사용할 경우 2개의 종속성이 필요하며 비네이티브 구현을 위해서는 4개의 종속성이 필요합니다.SLF4J와 Log4j2 API는 이 점에서 동일합니다.예를 들어 다음과 같습니다.

필수 의존 관계	API로 log4j-api 사용	SLF4J를 API로 사용
구현으로서 Log4j 2	2: log4j-api 및 log4j-core	4: slf4j, log4j-slf4j-param, log4j-api, log4j-core
구현으로서의 로그백	4: log4j-api, log4j-to-slf4j, slf4j, 로그백	2: slf4j 및 로그백

로깅을 "얼핏 보기보다 더 복잡하게 만드는" 고려 사항이 꽤 있습니다(따라서 수십 년 동안 치열한 싸움이 벌어집니다).

관심사의 분리

결국 코드는 '로그 데이터를 전송'하고 그 데이터는 '어딘가'에 도달합니다.그러나 그것이 어디에서 끝나느냐는 그것이 수집되는 목적에 달려있다.매우 복잡한 것은 현대의 소프트웨어는 다양한 컴포넌트로 구성되어 있으며, 이들 모두 로그가 필요할 수 있다는 사실이다.

최악의 경우를 생각해 봅시다: 모든 컴포넌트는System.out#println(String)적어도 모든 문장은 실행 순서로 되어 있지만, 어떤 컴포넌트가 각 출력을 생성했는지 식별하기가 쉽지 않을 수 있습니다.또한 일부 구성 요소는 사용되는 컨텍스트에 대해 지나치게 상세하게 설명할 수 있습니다.

다음으로 최악의 경우를 생각해 봅시다.모든 컴포넌트가 로깅 동작과 수신처를 제어하기 위한 독자적인 준비를 합니다.관리자는 단일 소프트웨어에 대해 수십 개의 로그 시스템을 구성해야 할 수 있습니다.이제 로그 문장이 함께 있지 않고 순서가 맞지 않습니다.모두 일관된 타임스탬프 전략을 가지고 있기를 바랍니다!

우리는 그 중간을 원합니다.코드가 'log this'라고 말할 수 있는 것과 관리자가 그 끝을 제어할 수 있는 것.

지나치게 짧은 이력

Log4J v1을 입력해 주세요.Log4J v1은, 「레벨」, 「어플랜더」, 「필터」, 「레이아웃」, 및 「콘텍스트」의 개념에 관한 문제에 대처하고 있습니다.이것은 계층형 「로그 네임스페이스」(Java 패키지 네임스페이스를 자연스럽게 활용하는 방법을 포함한다)에 의해 지원되는 개념 아키텍처입니다.

소프트웨어 내의 모든 컴포넌트가 같은 버전에 의존하고 있는 한, 그것은 모두 양호하고 양호했습니다.이런 것들이 유동적이던 시절이 있었다.SLF4J의 주된 기여는 컴포넌트 개발자의 관점에서 이들 개념을 안정적인 API로 '강화'하는 것이었으며, 관리자의 업무 수행 옵션을 왜곡하지 않았다.라이브러리는 SLF4J의 '패키지'에 의존할 수 있으며, 스택에서 몇 콜만 호출하면 '실장'에 대해 이야기할 수 있을 것으로 예상합니다.관리자는 로그를 일관성 있는 레코드로 구성하기 위해 자신에게 적합한 항목을 선택할 수 있습니다.

(소프트웨어가 컨테이너에서 실행되고 컨테이너에 로그 요구가 있으며 컨테이너에서 실행되는 앱이 동일하지 않은 경우에는 더 복잡합니다.자체 내부 로깅에 사용되는 Tomcat의 JULI 로깅은 Classloader 하위 컨텍스트에서 실행되는 앱을 '방해'합니다.)

Log4J에 의한 작업을 이상하게 혹평한 Java Community Process는 거의 동일한 개념의 아키텍처를 구현하기로 결정했습니다.java.util.logging디테일의 유연성은 거의 없습니다.단,j.u.l기본적으로 SLF4J의 의미적 풍부함의 하위 집합으로서, SLF4J를 표면으로 만드는 것은 쉬웠다.j.u.l.

Apache의 Commons Util Logging은 아마 그다지 필요하지 않았을 것입니다.Ceki의 Logback은 Log4J v1에는 없었던 관리 기능을 도입했습니다.SLF4J의 실장이나, 이러한 매우 리얼한 클래스 로더의 문제를 모두 해결할 뿐만 아니라, 관리자에게 매력적인 기능을 갖춘 적절한 실장을 제공합니다.

다양한 상황에 대한 로깅

그러나 로깅은 다양한 컨텍스트에서 수행됩니다.스레드를 과도하게 차단하지 않고 이러한 메시지를 매우 느린 I/O로 변환하여 로그 메시지를 계산하는 데 필요한 비용을 지불하지 않고 멀티 스레드 컨텍스트에서 일관성 있는 로그를 생성합니다.이 모든 게 중요해(그렇기 때문에)java.util.logging자주 사용되지 않습니다!)

경우에 따라서는 필요한 최적화가 개념 아키텍처에 영향을 미쳐 개발자 측 API에 영향을 미칠 수 있습니다.예를 들어, 로그 메시지가 필터링으로 인해 no-op이 될 경우 폐쇄로 인해 제공되는 기회는 확실히 속도를 높일 수 있습니다.이 기능을 사용하려면 SLF4J.next 또는 기타 API 중 하나를 고려해야 하며 Log4J2를 이 결정에서 제외할 필요는 없습니다.API 부분은 SLF4J가 제공하는 개념적인 슈퍼셋이기 때문에 SLF4J와 그 아래 구현의 외관을 만드는 것은 간단합니다.또는 관리자가 선호하는 브릿지에 직접 연결할 수도 있습니다.

앱 개발자는 관리자가 선택한 로깅 기능이 하나이고 모든 컴포넌트가 로그아웃할 수 있으면 상관없습니다.시설에서 SLF4J 및 Log4J2-the-API를 통해 메시지를 수신할 수 있다면 좋습니다.Log4J2 실장에서는, 이것만을 실시합니다.충분히 만족할 수 있습니다.어플리케이션은 Log4J2-the-API에서 제공되는 기회를 즐기면서도 SLF4J4J의 적절한 대응 라이브러리를 사용할 수 있습니다.관리자가 Log4J2-the-Implementation을 경멸하는 경우(어느 각도에서 봐도 왜 SLF4를 지원하는지 알 수 없습니다).로그 구현이 Log4J2-the-API를 지원하기를 기다리는 중입니다.네가 원하는 케이크를 먹을 수 있어.

도서관 개발자들에게 이것은 더 큰 문제이다.SLF4J는 널리 채택되어 있기 때문에 안전한 경로가 됩니다.로그가 라이브러리의 성공에 중요한 경우, 특히 멀티 스레드일 경우 로그 문을 생성하는 데 비용이 많이 들 수 있습니다.또한 로그 문이 최종적으로 소비되지 않을 경우 처리 작업을 생략하는 것이 좋습니다.또한 처리해야 할 로그 문이 대량으로 존재하거나 퍼포먼스가 중요하며 사용자가 애플리케이션을 실행할 가능성이 있습니다.Log4J2 구현의 이점을 다시 설명한 후 Log4J2를 수행합니다.하지만 SLF4J를 계속 사용하는 것으로 사용자로부터 기회를 빼앗는 것도 아닙니다.관리자는 필요에 따라 Log4J-the-implation을 사용할 수 있습니다.

요점

Log4J2에서 제공하는 기능을 원하는 경우 선택하십시오.필요 없는 경우 SLF4J는 많은 지원을 제공하는 성숙하고 안정적인 인터페이스입니다.SLF4J는 오픈 소스 인프라스트럭처의 중요한 부분입니다.Ceki는 그 대가로 많은 불평에 대해 지역사회에 큰 봉사를 했다.

그러나 최종적으로는 유능한 구현에 의해 지원되는 풍부한 API가 우세합니다.오늘의 안정은 내일의 침체이다.정제 과정은 계속 진행됩니다.가고 싶은 곳만 가면 버스에서 내릴 필요는 없어요.

언급URL : https://stackoverflow.com/questions/41498021/is-it-worth-to-use-slf4j-with-log4j2