止步不前的 Log4j 将何去何从
提到 Java 的 Logging 机制，我想绝大多数的 Java 开发人员都知道 Log4j 。
早在 Java 提供自己的 Logging API 之前， Log4J 就已经声名在外了，以至于当 Java 自己的 Logging API 出现后并没有赢得广泛的支持。
现在的 Java Logger 已经越来越多，比较广为熟知的有四个：Log4J，Java Logging API (又被称之为JUL)，Apache Commons Logging 和 SLF4J。
需要注意的是这四大框架里，后两个 Apache Commons Logging 和 SLF4J 更倾向于提供一个标准的 Logging API 接口，而不是 Logger 的实现，
像 Apache Commons Logging 一般都会和 Log4J 一起使用。
这么看来，Log4J 依然在当前众多 Logging Framework 中一枝独秀了。
但就是这个一个广为流畅的 Logger，如果我说 Log4J 已经快死了，你信么？？？
别说你不信，我也不信。但一个事实就是 Log4J 正在走下坡路， 在被其他 Logger 逐步代替的同时，本身的开发也是停滞不前。
我第一次注意到 Log4J 开发进度的问题还是在几年前。Java 5 (1.5）出的时候，由于有了众多的新特性，例如 Generics 和 Annotation，
导致了众多开源(非开源)项目启动了向 Java 5 转变的 Roadmap。后来证明，这个转变的成功与否，往往代表了一个项目的兴衰。
令我感触较深的是那时我用的几个 XML Parser 全都挂了。当然，旧的项目死了，新的项目顶上来，世界仍在继续，
那个时候 Log4J 也提出了自己的 Roadmap，Log4J 2.0！！！
但一直过了很久，此版本一直杳无音讯。后来又听说放弃了 Log4J 2.0 改为 Log4J 1.3。
好吧，其实版本号我并不是很介意， 1.3 虽然不如 2.0 响亮，我还是可以接受。
然后又过了很久，得知 Log4J 1.3 的开发被终止了......
结果就是到现在 Log4J 的版本仍然停留在 1.2，最新的是 Log4J 1.2.16。
我想很多人会说，不更新也无所谓，能用就成，反正不过是个 Logger 么。
那个时候我的想法也是如此。
我开始对 Log4J 产生厌恶程序是在开始开发 Hibernate 和各种 App Server 之后。
那个时候由于 IoC 和 ORM 模式的兴起，开发中开始遇到各种各样的 ClassLoader。
显然 Log4J 在 ClassLoader 上的设计是失败的，而且这个失败的影响是深远的。
我开始在各种情况下遇到 Log4J 的 ClassLoader Exception，无论是我的，还是第三方 Lib 的。
虽然总是能够用奇怪的方法绕过去，但随着花在这上面的时间越来越多，我不仅怀疑，Logger 不就应该设计的简单可用么？
那个时候正好有人在 Freenode 上推荐 SLF4J，我尝试了一下，那种感觉，
就好比“大话西游“里孙悟空一棒子打死了唐僧， A world without pain。
之后的几年里我一直用SLF4J, 或者 SLF4J + Log4J 也不会遇到问题。
直到最近，开始进行 OSGi 标准的开发。
Log4J 的噩梦又开始了。OSGi 的 ClassLoader 环境并不是标准的 Jre 环境，Log4J 又开始了 Endless Failure。
这还不是最糟的，很多版本的 Log4J 根本不能添加到 OSGi 的环境中，比如最新版的 Log4J 1.2.16。
OSGi 要求每个 Bundle（jar) 的 Manifest 里必须有特定的 OSGi 信息。
你没有也就罢了，也就是你不符合 OSGi 标准，但是事实上 Log4J 有， 他只是不能用。
我很怀疑他们在发布之前有没有测试过。更糟糕的是他们还把这些错误的程序放到了 Maven Repository 里，
这导致你经常会惊喜的发现，一次 mvn clean install 之后你得程序就不能用了。
最后我的解决办法就是使用 Log4J Over SLF4J (Bridge Log4J API to SLF4J API)。
还可以考虑使用第三方 Build 的 Log4J，例如 Spring 和 Eclipse 都自行发布了 OSGi 版的 Log4J。(这也可以从一个侧面看出这个项目的失败)
倒是还有些项目使用了 Log4J API 以外的部分(事实上 Log4J 根本没有单独发布API包，因此也不能怪用户)，上述的方法就不行了。
至此，我对 Log4J 感觉到很失望。
他唯一还值得称道的，就是茫茫多的 Appender，但99%的其实你根本用不到。
如果你正准备启动一个新项目，我建议你考虑 SLF4J + Logback。
事实上 Logback 正是一些 Log4J 的创立者离开之后，发起的新项目，也被人称之为 Log4J 的继任者。
在开源世界里，一个项目转入颓势往往难以扭转。
止步不前的 Log4J 究竟该何去何从？
