SLF4J

Talking about logging libraries

3rd party logging 라이브러리를 사용하든 직접 만든 logging 라이브러리를 사용하든, 사용하고있던 logging 라이브러리를 다른 것으로 바꾸기는 매우 힘든 일이다. logging의 특성상 logging 라이브러리의 API가 사용된 곳들이 어플리케이션 전체에 걸쳐 얇게 퍼져있기 때문이다. 그렇다면, logging 라이브러리를 사용하지 않거나, 항상 하나의 logging 라이브러리를 사용하면 문제는 해결되지 않을까?

현실은 그리 녹록하지 않다. 일단 logging은 trivial 하지 않은 어플리케이션을 개발할 때는 거의 필수적인 요소 중의 하나다. 또한, 여러 프로젝트를 하다보면 항상 하나의 logging 라이브러리를 쓰라는 법도 없다.

Logging libraries in Java

Java와 같은 platform의 경우에는 상대적으로 운이 좋은 편이다. Java 프로그래머라면 누구나 들어보았을 log4j라는 logging 라이브러리가 어느 정도 de facto standard 수준의 위치를 점유하고 있었기 때문이다. 심지어 다른 여러 언어로 porting 되기까지 했을 정도다. (log4c, log4cpp, log4r, log4cxx, log4net, log4perl, log4php)

하지만, Java에서도 logging 라이브러리의 편재화 현상은 나타나고 있는 듯 하다. 가장 큰 주범은 Java logging 라이브러리를 표준화하기 위한 노력으로(?), Log4J를 Java API 안으로 편입시킨 java.util.logging package를 들 수 있다.

사실 logging 라이브러리의 requirement는 어느 정도 정리되어있고, 따라서, 여러가지 라이브러리를 사용함으로써 얻는 이익은 거의 없다고 봐도 무방하다. 게다가, 여러가지 라이브러리가 존재하고 서로 다른 프로젝트를 할 때마다 각각을 새로이 배워야하는 것은 불필요한 노력이다. 이런 문제에 대한 근본적인 해법은 바로 표준을 만드는 것이다. 이미 존재하는 여러가지 대안들까지도 끌어안을 수 있기도 해야할 것이다. 사실 java.util.logging의 의도도 원래 선하고 순수한 것이었겠지만, 결과적으로는 사실상 두가지의 안이 혼재하는 상황이 벌어지고 말았다.

더욱 나쁜 것은 이 두가지 라이브러리들의 facade 역할을 하는 라이브러리들도 등장하기 시작했다는 것이다. 그 중의 하나가 요즘 사용해보고 있는 SLF4J이고 다른 하나는 Jakarta CommonsLogging 컴포넌트 (JCL)이다.

SLF4J

Simple Logging Facade for Java (SLF4J)는 위에서 언급했던대로, 여러가지 logging 라이브러리들의 facade에 해당한다. SLF4J 역시, log4j와 마찬가지로, level과 section 개념, 유연한 Handler/Formatter 구조를 가지고 있어, 기본적인 logging 라이브러리의 requirement를 만족할 뿐만 아니라, java.util.logging이나 log4j와 같은 logging 라이브러리를 wrapping 하고 있다. 물론 SLF4J의 API를 그대로 구현한 NLOG4J와 같은 native 구현들도 존재한다.

SLF4J의 API로부터 backend가 되는 logging 라이브러리의 API로의 mapping은 static하게 이루어진다. 그래서, wrapping 하고 있는 logging 라이브러리에 맞는 SLF4J 바이너리를 어플리케이션의 classpath에 넣어줄 필요가 있다. Dynamic하게 binding함으로써 쓸데없이 잃게 되는 성능을 생각하면 그리 커다란 문제는 아니다.

한가지 아쉬운 점은 logging level이나 handler 설정을 위한 설정 파일을 통합하고 있지는 않다는 것이다. 그래서, backend가 되는 logging 라이브러리의 레퍼런스를 찾아볼 필요가 생긴다는 귀찮음이 있다.

What a mess?

log4j, java.util.logging, JCL, SLF4J, … Java community가 왜 이런 짓을 하고 있는지 잘 이해가 가지 않는다. 더구나, C++ community에 표준 라이브러리의 중요성을 깨닫게 해준 Java community에서 말이다.

댓글 달기

이메일 주소는 공개되지 않습니다.

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.