How do Log4j, commons-logging, JDK-Logging and SLF4J relate to each other?

Are they alternatives, dependenci开发者_运维百科es, APIs or implementations of each other? And why do they exist?

Ah, logging frameworks in Java. Your question mixes 2 different types of libraries:

• log4j and JDK logging are libraries for handling logging
• Commons Logging and SLF4J are logging facades: you still need a real logging implementation (like log4j)

If you are writing a library that will be used in someone else's system, then you should use a logging facade because you do not know which logging framework they will use. In this case use SLF4J (Commons Logging is older and has some classloader issues).

If you control the whole application and can dictate which logging framework to use, you are free to choose your own preference. My preferred solutions are (in order of preference):

• Logback
• log4j
• JDK logging (in my opinion, a case of 'not invented here' by SUN)

I've been looking into this recently too. I've been using Log4J for years with Commons Logging and recently switched to SLF4J.

Log4j

Log4j is a framework for actually doing the log writing/distribution. It's extremely flexible: you can direct it to send log messages to files, syslog, remote monitoring, etc. You can also configure multiple loggers, logging categories, include context in entries, and so on. It's one of the most popular logging systems.

JDK Logging

The built-in JDK logging (which I've never used, to be honest) was added in JDK 1.4.2. From what I gather, it's not very popular because it's not as flexible as Log4j, but I'd welcome comments :).

Commons Logging and SLF4j

Both of these are façades on top of various logging frameworks that present a common interface for your application. For example, you can use CL/SLF4J in your application, and they will automatically detect an underlying logger implementation (Log4J, JDK logging, or a built-in logger that just delegates to System.err.println()). The benefit is that you or your end user can decide to switch out the underlying logging implementation at will, and they greatly simplify your implementation by removing many of the complexities of Log4J and JDK logging.

Most often you will see them layered.

SLF4J is purely an abstraction layer and is not, in itself, used for the actual outputting of logging but used by you in your code to log messages.

A typical setup is to use SLF4J to log in your code, then use log4j as the underlying "output" layer using an appropriate slf4j->log4j bridge (a jar you just include on your classpath). In order to merge logging from different sources, various bridges exist. For instance, many app servers (like tomcat) will use JDK-logging to avoid forcing a "non standard" logging framework on the deployed applications. For that purpose, slf4j has a bridge that will pick up all output from JDK-logging. So, this could be a stack

JDK-logging <- Your app-server or framworks might log using this
  |
(JDK->Slf4j bridge)
  |
Slf4j <- your application logs using Slf4j
  |
(Slf4j->log4j bridge)
  |
log4j <- log4j is just responsible for outputting to the appenders you configure (file, console etc)

SLF4J just is a generic API with different back-ends (any other logging system). Log4j and commons-logging (CL) different logging libraries, CL is a fossil. But they all have a fatal flaw, so sun have invented JDK logging.

As for me, I prefer SLF4J as most flexible and logback as a backend for it. Logback is most modern and have a lot nice features.