Log4j Must Die
Logging frameworks are the center of some discussions lately. See here and here.
Five years after the Java Logging API appeared in Java 1.4, and with the availability of the LumberJack implementation of the Java Logging API for prior versions of Java for just as long, I feel sad that Java people are still arguing about logging frameworks and the use of ill-conceived wrappers, and wrapper-wrappers.
Here's a simple truth that people who are still talking about logging frameworks are missing:
There is an adequate logging framework in the JDK for @#%*-ing five years.
Use it directly. Or, if you like wrappers, write a wrapper yourself. It can be done in less than a day. This is the path of least resistance.
Of course, if after careful consideration, the Java Logging API just isn't going to work for your project, then, yeah, go ahead and use whatever is out there that you like. You have my sympathy. But please keep the complaining to yourself.
Re: Log4j Must Die
Re: Log4j Must Die
I'm still sticking to log4j, because jdk logging is simply not cutting it for developers like me who rely on logging instead of running-the-whole-app-server-in-IDE-and-stepping-through-it for troubleshooting. Log4j's NDC, MDC, and some of the more flexible conf elements are extremely useful in that aspect.
From the system maintenance stand point, jdk logging isn't adequate at all. It doesn't support rolling log files by date. Without writing your own handler, you can't send logging to syslog or email - and those aren't just some weird requirements. Many support people (i.e. non-Java people) I have worked with link up their pagers to the production systems they are responsible for. And the ability to send a special category fatal message to an email address _transparently_to_the_app_ makes many people's lives easier.
For the same reasons, whenever we have a choice, we don't use wrappers because they are the least common denominators.