중간 규모의 Java 코드베이스에서 로깅 메커니즘을 업그레이드하고 있습니다. 메시지는 현재 Debug 클래스의 정적 메서드를 사용하여 기록되며 SLF4J 또는 commons-logging과 같은 것으로 전환하는 것이 좋습니다.추가 레이어에서 로깅 프레임 워크를 래핑 할 가치가 있습니까?
애플리케이션 아키텍트는 SLF4J에 종속성을 캡슐화하기를 원합니다 (아마도 앞서 말한 Debug 클래스로 래핑함으로써). 이렇게하면 향후에 로깅 구현을 쉽게 변경할 수 있습니다.
SLF4J가 이미 구체적인 로깅 구현을 추상화하고 있기 때문에 이것은 과도한 것처럼 보입니다.
SLF4J와 같은 타사 로깅 추상화를 에 다시 래핑 할 가치가 있습니까? 자생 추상화?
전적으로 당신과 동의합니다. 래퍼 래퍼가 손에서 빠져 나오고 있습니다. SLF4J가 다른 로깅 시스템을 쉽게 감쌀 수있는 방법을 건축가가 깨닫지 못해 "변화하는 구현"이 또 다른 층의 포장 없이는 완벽하게 실현 될 수 있다고 생각합니다.
실제로. SLF4J에서 완전히 전환해야하는 이유는 2 가지 밖에 없습니다. SLF4J가 완전히 멸절되거나 완전히 새로운 방식의 로깅을 발명 한 사람이 지금과는 완전히 다른 방식입니다. 둘 다 똑같이 보이지 않을 것 같습니다 :) – harto
@ harto의 의견에 +1은 사운드 버드가 완벽하기 때문에!-) –
나는 건축가가 실제로 slf4j를 시도하지 않았고 구현이 아니라 API라는 사실을 깨닫지 못했다고 생각한다. –
로깅 프레임 워크를 나중에 전환하려는 경우 로거를 전환 할 수있는 위치에 추가 레이어를 추가하는 것이 좋습니다. 그렇지 않으면, 그들이 당신이 필요로 할 모든 것을 제공한다면 (물론 수정 구슬을 사용하여) 그 프레임 워크에 대한 의존성은 아마도 괜찮을 것입니다.
현재 설정에서 유연성을 변경할 수있는 경우 래퍼가 필요하지 않습니다.
Architecture Astronaut에 따르면 slf4j는 이미 log4j와 같은 다른 로깅 구현을위한 래퍼로 작동 할 수 있다고 설명합니다. 따라서 앞으로 다른 로거를 사용할 필요가 있고 slf4j 용 어댑터가 없다면 필요가 생길 때 작성할 수 있지만 어댑터를 사용하면 전체 로깅 프레임 워크를 작성하는 대신 다른 어댑터를 감쌀 것입니다. 로깅 프레임 워크와 그것에 대한 프레임 워크를 설계하고 자신의 어댑터를 작성해야합니다.
나는 그것을 감싸는 것이 좋겠지 만 언급 된 이유는 아닙니다. 관심사가 다른기구를 위해 교환하는 기능 인 경우에, java.util.logging 또는 SLF (java.util.logging는 포장지로 사용하기 쉽지 않다, 그러나 아주 가능하다)를 사용하고, 멀리 교환하십시오. (또 다른) 래퍼를 사용하는 이유는 코드에서 적절한 로깅 방법을 체계화하는 것입니다. 일반적으로 응용 프로그램에는 모든 시스템 오류 (예 : 예외가 있음)와 같은 하위 집합이 필요하거나 표준 로깅 수준을 사용할시기에 대한 구체적인 지침이 필요합니다. 이러한 결정은 몇 가지 방법으로 캡슐화하여 대규모 코드 기반에서보다 일관된 로깅 결정을 내릴 수 있습니다.
그러나 구현의 전환을 가능하게하려는 동기가 있다면 바퀴를 재발 명하지 마십시오. SLF는 업무에 적합하며 사용하기에 적합합니다.
한 가지 예외가 있습니다. 코드가 무의미하게 많은 가능한 응용 프로그램 서버에 배포되어야하는 경우 로깅 선택이 프레임 워크가 사용하는 모든 버전의 이전 버전 또는 새 버전과 충돌 할 위험이 없도록해야합니다.
적절한 로깅 방법에 대한 좋은 지적. 로깅이 일관된 방식으로 수행되도록하는 것이 중요 할 것입니다. 배포 고려 사항과 관련하여 코어 라이브러리는 웹 응용 프로그램의 일부로뿐만 아니라 데스크톱에도 배포됩니다. 그러나 일반적으로 Tomcat 6 만 사용하므로 걱정하지 않아도됩니다. – harto
독점적 로깅 래퍼를 추가하면 로깅 백엔드의 호출 위치 기능이 손상 될 수 있습니다. 그 외에도 이미 충분히 사용 된 타사 모듈이 대부분 버그가없는 반면 (벌레 잡기, 버그 수정) 지원해야하는 모듈이 하나 더 있습니다. – Huxi
주로 상대적인 방식으로? 이봐, 사용자를 놀라게하지 마라! :-) – Ceki
모든 래퍼의 문제는 당신이 실제로 포장거야, 그리고 당신이 제공하는 것입니다있는 기능이 방법의 결정이다 :
현재 사용중인 Debug 클래스를 잘 모르겠지만 꽤 기본이라고 생각합니다.
당신은 아마 없을 것이다 기능
디버그 클래스 이 당신을 위해 실제로 매우 좋은 :) 아주 기본적인 경우는
그것은 당신이 글로벌 검색 & destr을 수행하여 SLF4J로 전환 할 가능성이 할 수있는 것을 의미한다. .. err ... 대체하십시오.
도 Should new projects use logback instead of log4j?, What’s Up with Logging in Java?, Which log4j facade to choose?, Find a way in the java logging frameworks scene. 및 Do you find java.util.logging sufficient? 참조)
은하지만 ... 백업을 확인합니다. (Spoiler : java.util.logging은 사용하지 말아주세요.)
건축가가 래퍼 (즉, SLF4J)를 포장하려는 동기의 동기는 SLF4J에서 애플리케이션을 분리하는 것입니다. 분명히, 응용 프로그램 내에서 SLF4J API를 호출하면 SLF4J에 대한 종속성이 생깁니다. 그러나 아래에 설명 된대로 격리 원칙을 반복적으로 적용하려는 것도 똑같이 정당합니다. 리처드 도킨스 (Richard Dawkins)의 질문을 상기시켜줍니다. 하나님이 우주를 창조 하셨다면 누가 신을 창조하셨습니까?
실제로 SLF4J를 래핑하는 래퍼에 격리 원칙을 적용 할 수도 있습니다. SLF4J-wrapper가 SLF4J보다 다소 열등한 경우 분리의 원인이 부적절합니다. 가능한 경우 래퍼가 원본과 같거나 초과하는 경우는 드뭅니다. SWT는 주목할만한 반대 사례로 인용 될 수 있습니다. 그러나 SWT는 상당한 비용을 들여 대규모 프로젝트입니다. 요컨대 SLF4J에 대한 정의에 따라 SLF4J-wrapper가 달라집니다. 동일한 일반 API를 사용해야합니다. 향후 로깅 API가 새롭고 상당히 다른 경우, 래퍼를 사용하는 코드는 새 API로 SLF4J를 직접 사용하는 코드로 마이그레이션하는 것도 똑같습니다. 따라서 래퍼는 코드의 미래를 보장하지는 않지만 추가 간접 참조를 추가하여 코드를 더 무겁게 만들 수 있습니다.
간단히 말해서 더 나은 방법이 없더라도 SLF4J를 래핑하는 시간을 낭비하지 않아야합니다. 래퍼의 추가 가치가 0에 가깝기 때문입니다.
또한 주제는 SLF4J FAQ entry에 있습니다.
건축가는 slf4j가 무엇인지 이해하지 못했습니다. –