SLF4J는 특별한 클래스 로더 기계에 의존하지 않습니다. 실제로 각 SLF4J 바인딩은 컴파일 타임에 하나의 특정 로깅 프레임워크만 사용하도록 하드와이어됩니다. 예를 들어 slf4j-log4j12-1.7.26.jar 바인딩은 log4j를 사용하기 위해 컴파일 타임에 바인딩됩니다. 코드에서 slf4j-api-1.7.26.jar 외에도 선택한 바인딩을 적절한 클래스 경로 위치에 하나만 놓기만 하면 됩니다. 클래스 경로에 두 개 이상의 바인딩을 배치하지 마십시오. 다음은 일반적인 아이디어의 그래픽 그림입니다. 다른 경우와 마찬가지로 동일한 코드 베이스가 정상적으로 실행됩니다. 이 설정을 실행하는 전체 프로젝트의 예는 여기에서 확인할 수 있습니다. SLF4J 바인딩은 SLF4J API와 사용하려는 기본 로깅 프레임워크 간의 적응 계층입니다. 다음 링크를 통해 로깅 프레임워크가 http://www.slf4j.org/manual.html#binding 있는 적응 항아리를 알 수 있습니다. SLF4J 바인딩은 slf4j-jdk14.jar 또는 slf4j-log4j12.jar와 같은 아티팩트를 기본 로깅 프레임워크(예: java.util.logging 및 log4j)에 바인딩하는 데 사용됩니다. 매핑된 진단 컨텍스트에는 기록되는 모든 메시지에 컨텍스트 정보를 배치하는 작업이 포함됩니다. 이렇게 하면 타임스탬프와 함께 로그 메시지에 대한 컨텍스트가 제공됩니다.
예를 들어 쇼핑 응용 프로그램에서 모든 로그 메시지에는 주문 ID가 포함되어 있으므로 주문 관점에서 메시지를 분석하거나 디버깅할 수 있습니다. API의 키-값 쌍 변형은 키-값 쌍을 분리 개체로 저장합니다. org.slf4j.Logger 클래스에서 배송으로 기본 구현 메시지에 키 값 쌍을 접두사. 로깅 백 엔드는 원하는 대로 출력을 자유롭게 사용자 정의할 수 있습니다. 로그백 클래식 기본 로깅 프레임워크로 로그백 클래식을 사용하려는 경우 아래와 같이 pom.xml 파일에서 “ch.qos.logback:logback-classic”을 종속성으로 선언하기만 하면 됩니다. 로그백 클래식-1.2.3.jar 외에도 slf4j-api-1.7.26.jar뿐만 아니라 로그백 코어-1.2.3.jar를 프로젝트에 끌어올 수 있습니다. 로그백 코어-1.2.3 또는 slf4j-api-1.7.26.jar에 대한 종속성을 명시적으로 선언하는 것은 잘못된 것이 아니며 Maven의 “가장 가까운 정의” 종속성 조정 규칙을 통해 해당 아티팩트의 올바른 버전을 부과해야 할 수 있습니다. 초기화 시 SLF4J가 slf4j-api 대 바인딩 버전 불일치 문제가 있을 수 있다고 의심되는 경우 의심되는 불일치에 대한 경고를 내보올 것입니다. 클래스 경로에서 slf4j 바인딩을 찾을 수 없기 때문에 이 경고가 인쇄됩니다. 클라이언트의 관점에서 slf4j-api의 모든 버전은 호환됩니다.
slf4j-api-N.jar로 컴파일된 클라이언트 코드는 N 및 M에 대해 slf4j-api-M.jar로 완벽하게 잘 실행됩니다. 바인딩 버전이 slf4j-api.jar의 버전과 일치하는지 확인해야 합니다. 프로젝트에서 지정된 종속성이 사용하는 slf4j-api.jar 버전에 대해 걱정할 필요가 없습니다. 유창한 로깅 API를 사용하면 로거 인터페이스의 메서드 수에 조합폭발없이 다양한 유형의 데이터를 org.slf4j.Logger로 사양할 수 있습니다. 로깅 예제를 직접 살펴보겠습니다. 아래 의 응용 프로그램에 대한 초기 설정을 살펴보겠습니다. 우리의 프로젝트는 종속성 관리자로 Maven을 사용하고 응용 프로그램의 종속성은 우리가 그들을 만날 때와 같이 자세히 설명 될 것입니다. 클래스 경로에 바인딩을 추가하면 경고가 즉시 사라집니다.
클래스 경로가 포함되도록 slf4j-simple-1.7.26.jar를 추가한다고 가정하면 2.1 로그백 클래식 선언, 로그백 코어 및 slf4j-api SLF4J를 통해 JCL의 구현, 즉 jcl-over-slf4j.jar를 통해 프로젝트가 SLF4J로 마이그레이션할 수 있습니다. JCL을 사용하는 기존 소프트웨어와의 호환성을 깨지 않고 단편적으로 사용할 수 있습니다.
