slf4j를 log4j2와 함께 사용할지 여부를 결정할 수 없습니다. 온라인 게시물에 따르면 성능 저하가없는 것처럼 보이지만 실제로는 필요합니다.
또한 다음 포인트는 log4j2를 선호합니다.
- SLF4J는 애플리케이션이 문자열을 기록하도록합니다. Log4j 2 API는 텍스트를 로깅하려는 경우 모든 CharSequence 로깅을 지원하지만 모든 개체를있는 그대로 로깅하는 것도 지원합니다.
- Log4j 2 API는 메시지 개체 로깅, Java 8 람다 식 및 가비지없는 로깅을 지원합니다 (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
- 지연 로깅을위한 Lambda
- 문자열 대신 모든 개체 기록
- 가비지 프리 : 가능한 경우 varargs를 생성하거나 String을 생성하지 마십시오.
- CloseableThreadContext는 항목 사용이 끝나면 MDC에서 항목을 자동으로 제거합니다.
( SLF4J에서 사용할 수없는 10 개의 Log4j2 API 기능 참조 에서 을 참조하십시오.)
애플리케이션은 기본 Log4j2 코어 구현에 고정되지 않고도 Log4j2 API의 이러한 풍부한 기능을 안전하게 사용할 수 있습니다.
SLF4J는 여전히 안전 밸브이며, 애플리케이션이 더 이상 SLF4J API에 대해 코딩해야한다는 의미는 아닙니다.
공개 : Log4j2에 기여합니다.
업데이트 : Log4j2 API에 대한 프로그래밍이 “파사드를위한 외관”을 도입하는 데 약간의 혼란이있는 것 같습니다. 이 점에서 Log4j2 API와 SLF4J 사이에는 차이가 없습니다.
두 API 모두 네이티브 구현을 사용하는 경우 2 개의 종속성이 필요하고 네이티브가 아닌 구현의 경우 4 개의 종속성이 필요합니다. SLF4J와 Log4j2 API는이 점에서 동일합니다. 예를 들면 :
