refactoring을 하다보면 AAA라는 클래스를 지우고, BBB라는 클래스를 AAA로 바꾸고 싶을 때가 있다. eclipse의 refactoring 기능을 사용하면 이러한 refactoring은 매우 자연스럽고 쉽게 수행할 수 있다. 하지만, commit할 때가 문제다. 다음은 이를 시도할 때 subclipse (정확히는 subversion) 에서 발생하는 에러다.

delete --force AAA.java
 D AAA.java
move BBB.java AAA.java
 Entry already exists
svn: 'AAA.java' is scheduled for deletion; it must be committed before it can be overwritten

subclipse의 문제가 아니라 file 이름 기반으로 entry들을 관리하는 subversion 자체의 문제로 보인다. 물론 해결하는 방법이야 존재한다. 가장 간단하게는 deletion과 rename을 따로 commit하는 것이 바로 그것이다. 하지만, 항상 code repository에는 working version 만을 넣겠다는 rule을 깨뜨려야하기도 하다.

현재 하고 있는 일이 간단한 웹 어플리케이션을 만드는 일이라 apache + mod_ruby를 사용하고 있는데, 그냥 단순히 apache + CGI + ruby를 사용하는 것에 비해서도 좋지 못한 선택이 되고만 것 같습니다.

라이브러리 등에 이미 존재하는 클래스를 override할 수 없는 문제라든가 HTTP header와 관련해서 시키는대로 했는데도 불구하고 제대로 동작하지 않아서, Apache Runtime에 접근해서 직접 조작해주어야 하는 짜증스러움이 있군요.

아햏햏한 문제는 또 있습니다. 다른 개발자가 항상 사용할 수 있어야하기 때문에, 테스트 버전과 개발 버전을 하나의 apache 서버에서 돌리고 있습니다만, 하나의 버전에 접근한 후 다른 버전에 접근하면 알 수 없는 에러가 발생합니다.

nohmad 옹에게 문의해보니 대뜸 mongrel + Nitro + Og + amrita2을 쓰시라고 하시는군요. 굳이 Nitro나 amrita는 아니더라도, 일단 mongrel이나 webrick 같은 ruby로 된 web server를 사용해보는 것도 괜찮을 것 같습니다. RoR과 같은 web application development framework를 선택하지 않은 것은 DB를 쓸 정도로 복잡한 어플리케이션이 아니었기 때문이었는데, 차후에 DB를 사용할 필요가 생기면 그 때 정도에 고려해도 무난할 듯 하군요.

온라인 구독권을 판매하던 DDJ가 어느새 온라인으로 기사를 공개하는 정책으로 선회했나봅니다. PDF Issue Archive 까지도 제공합니다. CUJ는 폐간되고 DDJ로 흡수된 건 알고 계시죠? 따라서, The New C++ 과 같은 칼럼도 전부 DDJ에서 볼 수 있게 되었습니다.

대전에 내려가있는 동안, 구독을 온라인 구독만 하고 있었는데, 다시 종이로 구독을 시작했습니다. ;-)

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 Commons의 Logging 컴포넌트 (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에서 말이다.