Develop Reference

Logging Method for Spring Based Library

I created a library using Java & Maven that contains some common Spring functionality for reuse in various Spring-Based projects.
The library will obviously need to log error/information messages. Spring allows the developer to use whichever logging library they prefer, how do I make my library do the same?

Spring uses commons-logging which is a logging facade that allows you to write logging code without knowing what is the actual logging framework.
Depending on what you have configured, the commons-logging will then channel the logging messages to the actual implementation. This allows you to write your code using commons-logging, and the users to use any logging framework supported by commons-logging.
Personally I would go with slf4j (Simple Logging Facade 4 Java) which is similar to commons-logging, but newer and functions in pretty much the same way.
It's also possible to bridge different libraries or facades, so that even if libraries use different logging frameworks they will always end up in the logger of your choice. Looking to the monitor to my right there are bridge libraries as follows: jcl-over-slf4j (commons-logging to slf4j), log4j-over-slf4j and jul-to-slf4j (java.util.logging to slf4j).
Note: See the link in comments for more information about how slf4j = good, JCL = bad ;)

Hibernate uses apache commons logging and slf4j - why are 2 logging abstraction layers needed?

I am not so experienced in the java logging libraries world.
I started using hibernate and then saw I needed to include apache commons logging library and sl4j library.
The actual logging library is log4j - so I included that library too.
After reading about apache commons logging and sl4j libs, I understand that they both represent an abstraction layer for logging with another library (log4j in my case).
Why are 2 abstraction levels needed ?

In a perfect world, these multiple logging API are not needed, but unfortunately, there is no clear standard, so different libraries (and Hibernate is a big project with many dependencies and sub-projects) use different logging API, and as a user, you have to provide all of them.
The quasi-standard was Log4J, until Sun decided it needed to include its own version (java.util.logging) into the JDK. That made it a two-horse race, and Commons Logging was designed to provide a unified interface to both (and any others). Unfortunately, Commons Logging had some short-comings, too, so the current favourite is SLF4J. SLF4J tries to help with cleaning up the mess by providing bridges to all other API, too.

Hibernate uses slf4j over apache commons logging.
Legacy code.
Inside of hibernate are full of commons logging usage. And simplest way to move from commons logging to desired logging library was adding slf4j layer. Now you can use one from popular logging library with Hibernate, which inside still use commons logging's interfaces.
Also there were another reasone to move to slf4j.

How do I set up commons-logging to use logback?

We use slf4j + logback, and happened to have some third-party libraries which use commons-logging. How do I set it up to use logback?

The answer is to not use commons-logging.jar, since SLF4J was designed to do what commons-logging does but better. As #MahdeTo refers to, you need to use jcl-over-slf4j.jar.
Check out the documentation from the slf4j website on migrating from commons-logging.

I come across this question too, and found out jcl-over-slf4j.jar indeed can solve the problem, I couldn't understand that why commons-logging couldn't use logback automatically, since commons-logging is log interface and logback is implementation, they should integrate automatically, until I found this:
The Apache Commons Logging (JCL) provides a Log interface that is
intended to be both light-weight and an independent abstraction of
other logging toolkits. It provides the middleware/tooling developer
with a simple logging abstraction, that allows the user (application
developer) to plug in a specific logging implementation.
JCL provides thin-wrapper Log implementations for other logging tools,
including Log4J, Avalon LogKit (the Avalon Framework's logging
infrastructure), JDK 1.4, and an implementation of JDK 1.4 logging
APIs (JSR-47) for pre-1.4 systems. The interface maps closely to Log4J
and LogKit.
Obviously not all the log interface can integrate nicely with log implementation which mean, if you really want to use logback, jcl-over-slf4j.jar is your only solution now because JCL only support Log4J, Logkit, JDK 1.4.

Just add jcl-over-slf4j to the dependencies of your project (check current version at https://search.maven.org/search?q=g:org.slf4j%20AND%20a:jcl-over-slf4j&core=gav)

for those all who wants to keep the final package size smaller; checkout
mvn dependency:tree result of your project and if any dependency to commons-logging exists, exclude them as well. Since the jcl-over-slf4j.jar contains both Log and LogFactory classes with exact same package structure, these commons-logging jars will be extra on your final package.

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

Are they alternatives, dependencies, 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.

java logging vs Log4j in Spring framework. Which one is the most suitable

We are developing a web-based application in Java using the Spring framework. We are wondering which Logging system would be the most appropriate for it, whether Log4j or JUL (java.util.Logging), which is integrated with jdk. As far as I'm concerned, the former is more popular among developers and offers higher customization options, but I'm not sure which is simpler to adapt with spring.
any help will be appreciated.
thanks!

Before you start with log4j, look at logback. Log4j shouldn't be used for new projects anymore. If you have legacy code that needs any logging framework, use slf4j to make the old code talk to logback (or log4j if you must).
The main reasons you should not use JUL is that it implements the bare minimum that you need for logging, the configuration is hard at best and, if you use any component that doesn't use it, you'll have to deal with two logging frameworks.

Regardless of which logging framework you use in your own code, as far as I can remember, Spring has a hard dependency on commons-logging. You can still use whatever you like for your own logging (I'd recommend SLF4J as your facade, with logback as your implementation), but Spring internally needs commons-logging. Whether you want to depend on multiple frameworks is your choice; it shouldn't prove problematic.

Spring uses commons logging, which is a log abstraction facility but has issues that sl4j doesn't have. Hibernate moved to slf4j - I would like to see spring do the same, but I don't think they have any plans in this regard.
So as long as your log abstraction facility (use slf4j) logs to the same logging framework as you've configured commons logging in spring, then you're good. One log configuration for both. You might find an adapter for logback for commons and slf4j.

Since the other responses didn't actually answer your question, I thought I'd have a stab at it.
Firstly, java.util.logging is horrible. It's a pain to use, and a pain to configure. Log4J is nicer on both counts. However, you should pick whichever one you're most comfortable with. Spring uses commons-logging, which in turn will use either log4j (if found on the classpath) or java.util.logging otherwise. In otherwords, if your application already has log4j present, then Spring will effectively use that, and so should you. If log4j is not already present, then either use java.util.logging (if you choose to), or add log4j to your classpath and use that.