일부 Java 로깅 항목을 파헤 치고 slf4j에 대해 질문합니다. 항상 .java 파일에서 동일한 방식으로 로깅을하고, 로거 이름에 대해서만 염려하고, .jar 및 .properties/.xml 파일을 가지고 모든 로깅 구성을 수행하는 것이 매우 편리합니다.slf4j를 피할 이유가 있습니까?
어떤 프로젝트에서 기본적으로 slf4j을 사용하거나 사용하지 않는 이유는 무엇입니까?
이 특별한 경우 log4j는 실제로 로깅을 수행하고 (일부는 파일로, 일부는 stdout으로, 일부는 데이터베이스로), 이는 maven 프로젝트입니다.
나는 단순한 "예, 그것을 위해서"또는 "아니오, slf4j를 사용하여 경험이있는 누군가의 문제 X를 묻습니다."라고 기대하고 있습니다.
우리는 지금 SLF4J API를 1.5 년 동안 로깅했습니다. 그 전에 우리는 log4j을 직접 사용했습니다. 이제 우리는 logback intermezzo와 함께 jboss.logging을 사용하고 모든 프레임 워크가 변경 될 때 코드에서 0 행을 변경해야했습니다.
그래서, 갈)
확실히 slf4j를 사용하십시오. 그것은 오늘날의 표준 공통 로깅 인터페이스이며, 실제 로깅 구현을 연결하는 것과 관련하여 마침내 적합합니다. Log4j는 log4j를 처음부터 끝낸 log4j의 후계자이지만, log4j에서 바로 처리 할 수 없었던 문제는 해결할 수 있습니다.
SLF4J 그냥 대신 Log4jLoggerAdapter 또는 LogBack의 JDK14LoggerAdapter을 사용하여에 보관하기 때문에 좋아, 내가 실제로 직접 log4j에를 사용하는 대신에 SLF4J를 사용하지만 결국, 나는 시도 쳤고 의존성을 조정하여 작업하게하려면 ...
해당 프로젝트는 Maven2로 작성된 Jenkins 플러그인으로, 이는 합병증의 원인 일 수 있습니다. ".pom에 이러한 종속성을 넣는 것"으로는 실제로 작동하지 않았습니다.
그래서 내 자신의 질문에 대답하기 위해 slf4j를 사용하지 않는 이유는 덜 움직이는 부분, 덜 의존성, 적은 설명서 및 문서를 읽는 것이므로 SO/메일 링리스트에서 질문하는 것이 적다는 것입니다.
slf4j가 JDK14LoggerAdapter를 사용할 수있는 유일한 방법은 sfl4j-jdk14 브리지에 의존하고 있기 때문입니다. Maven을 사용하거나 사용하지 않은 채 몇 년 동안 slf4j를 사용 했으므로 여기서 고통의 포인트는 slf4j가 아니라 Maven 경험이라는 것을 나에게 알려줍니다. Maven 의존성에 대한 도움말은 http://slf4j.org/faq.html#excludingJCL을 참조하십시오. –
@ ThorbjørnRavnAndersen 나는 결국 slf4j로갑니다. "트릭"은 개발 단계에서이를 걱정하지 않고 배포 할 때 동적 로깅 항목을 어디에 두어야 하는지를 파악하는 것입니다. 로깅을 제어하려고하지만 배포를 제어 할 수없는 경우에만 어려워집니다. – hyde
우리가하는 것처럼하는 것이 좋습니다. 두 단계 프로세스로 만듭니다. 첫 번째 단계는 다양한 항아리 건물을 만드는 것입니다. 두 번째 단계는 배포를 만드는 것입니다. 이렇게 분리하면 많은 일이 더 명확 해지며 두 단계를 거쳐 더 많은 유연성을 얻을 수 있습니다. –
참조 http://stackoverflow.com/questions/6691058/best-logging-system 및 http://stackoverflow.com/questions/4516932/difference-between-slf4j-and-log4j – ramsinb
이유가 없습니다. 그것을 피하십시오. – Subin