[SPRING] Apache Commons Logging의 런타임 검색 알고리즘 문제는 무엇입니까?

Apache Commons Logging의 런타임 검색 알고리즘 문제는 무엇입니까?

Dave Syer (SpringSource)는 그의 블로그에 다음과 같이 씁니다.

왜? 런타임 검색 알고리즘의 문제점은 무엇입니까? 공연?

해결법

1. ==============================

   1.아니요, 성능이 아니라 클래스 로더의 고통입니다. JCL 탐색 프로세스는 런타임에 로깅 프레임 워크를 찾기 위해 클래스 로더 해킹에 의존하지만이 메커니즘으로 예기치 않은 동작, 클래스로드 문제를 디버그하기가 어려워 복잡성이 증가하는 등 많은 문제가 발생합니다. 이것은 Commons-logging API (JCL에서 관찰 된 메모리 누수 문제를 언급 함)를 채택하기 전에 Think의 Logy, Log4J, Logback의 작성자 인 Ceki에 의해 잘 캡쳐되었습니다.

   아니요, 성능이 아니라 클래스 로더의 고통입니다. JCL 탐색 프로세스는 런타임에 로깅 프레임 워크를 찾기 위해 클래스 로더 해킹에 의존하지만이 메커니즘으로 예기치 않은 동작, 클래스로드 문제를 디버그하기가 어려워 복잡성이 증가하는 등 많은 문제가 발생합니다. 이것은 Commons-logging API (JCL에서 관찰 된 메모리 누수 문제를 언급 함)를 채택하기 전에 Think의 Logy, Log4J, Logback의 작성자 인 Ceki에 의해 잘 캡쳐되었습니다.

   이것이 정적 바인딩을 사용하는 SLF4J가 생성 된 이유입니다.

   Ceki가 SLF4J의 저자이기 때문에, 그의 기사가 편견을 가지지 만, 나를 믿지 않는다고 생각할지도 모릅니다. 그리고 그는 자신의 기사를 참고하기 위해 많은 참고 자료 (증거)를 제공하고 있습니다.

   요약하면 다음과 같습니다.

2. ==============================

   2.커먼즈 로깅은 중량이 많은 로깅 API 인 log4j, java.util.logging 또는 다른 지원되는 로깅 API 위에 배치되는 경량 로깅 패브릭입니다.

   커먼즈 로깅은 중량이 많은 로깅 API 인 log4j, java.util.logging 또는 다른 지원되는 로깅 API 위에 배치되는 경량 로깅 패브릭입니다.

   발견 알고리즘은 실행시에 사용하는 로깅 API를 결정하기 위해 로깅 (commons logging)을 사용하여 API를 통해 로그 기록을 기본 로깅 API로 보낼 수 있습니다. 이 이점은 로깅을 수행하는 라이브러리를 작성하려는 경우 라이브러리의 사용자를 특정 중량 라이브러리로 묶어 두는 것을 원하지 않는다는 것입니다. 코드 호출자는 log4j, java.util.logging 등을 통해 로깅을 구성 할 수 있으며 런타임시 commons logging이 해당 API로 전달됩니다.

   공유지 로깅을위한 일반적인 불만 사항 :

   인지 된 장점이없는 복잡한 클래스 경로 계층 구조에서 예상치 못한 복잡성뿐만 아니라 예상치 못한 복잡성으로 인해 커먼즈 로깅 사용자가 불안해합니다. 이 선택이 당신에게 강요 될 수도 있다는 점을 감안할 때 사용자를 공감할 수는 없습니다. commons-logging 사용에 대한 강력한 논쟁에 대해서는이 기사를 참조하십시오.

3. ==============================

   3.나는 "믿을만한 사람이 아니었다"는 말을 할 수 없다. 나는 나 자신을 위해서만 말할 수있다.

   나는 "믿을만한 사람이 아니었다"는 말을 할 수 없다. 나는 나 자신을 위해서만 말할 수있다.

   Commons Logging은 "실제"로깅 프레임 워크가 무엇이든 상관없이 Log4j, Logback 또는 무엇이든 상관없이 가장 위에있는 외관입니다.

   로깅 외관의 아이디어는 앱이 런타임시 로깅 구현을 결정할 수있는 유연성을 확보한다는 것입니다. 정면은 런타임에 로깅 구현을 찾을만큼 충분히 똑똑합니다.

   내 오래된 Java 응용 프로그램은 Log4j를 직접 사용합니다. 잘 작동하고, 나는 그들을 바꿀 필요가 없다. 새로운 Java 응용 프로그램은 Logback을 사용합니다. 동적으로 로깅 프레임 워크를 선택할 수있는 능력은 내 앱 중 어느 것도 필요하지 않을 것이라고 생각합니다. 물론 다른 사람들의 마일리지가 다를 수 있습니다.

   편집 : Commons Logging의 근거에 대해서는 틀린 것처럼 보입니다. @ Pascal Thivent가 제공 한 링크, 특히 첫 번째 링크는이 점을 훨씬 잘 설명합니다.

4. ==============================

   4.Commons Logging은 런타임시 log4j 또는 java.util.logging. *을 사용할지를 결정하는 논리를 포함합니다.

   Commons Logging은 런타임시 log4j 또는 java.util.logging. *을 사용할지를 결정하는 논리를 포함합니다.

   그 코드는 심각하게 부서 지곤했으나 본질적으로 JUL과 만 작업했습니다.

   이것에 대한 경험을 바탕으로, 정적 바인딩을 사용하는 (또는 1.6 버전에는 확실하지 않은) slf4j가 log4j, JUL 또는 log4j 포크 로그백 (그리고 그 이상)을 사용하기위한 적절한 프레임 워크를 선택하도록 작성되었으며, 다음을 포함합니다. 기존 Commons Logging 코드가 slf4j를 투명하게 사용할 수 있도록하는 브리지.

   가능한 경우 slf4j로 이동하십시오.

from https://stackoverflow.com/questions/3222895/what-is-the-issue-with-the-runtime-discovery-algorithm-of-apache-commons-logging by cc-by-sa and MIT license