I'm writing a library that gathers various functions that I'll be using in different applications. I want it to generate log statements visible for the user of the library, i.e., if I'm building an application and I'm using the library, I want the library to generate log statements visible to me. How do I do that? Since the log file will be configured by the developer of the application, how will my library know how to log?
-
Take a peek at the Spring framework. Specifically, the Dependency Injection capability is the part that is most useful to you. – cdeszaq Mar 16 '12 at 16:18
4 Answers
If you are developing a library the others will include in their application you should use a logging facade. Otherwise you force the users of your library to configure and include the logging framework you have choosen in addition to the framework they chose for their application.
For instance if you use log4j but the developer using your library uses logback he will have to include a log4j configuration file and the log4j jar (or take other measures) to make your library happy.
Logging Facades solve this problem (from Apache Commons Logging):
When writing a library it is very useful to log information. However there are many logging implementations out there, and a library cannot impose the use of a particular one on the overall application that the library is a part of.
The Logging package is an ultra-thin bridge between different logging implementations. A library that uses the commons-logging API can be used with any logging implementation at runtime. Commons-logging comes with support for a number of popular logging implementations, and writing adapters for others is a reasonably simple task.
Or the reasoning from SLF4J:
The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time.
Candidates for logging facades are:
-
Your example is misleading. The developer can use SLF4J API for is code and log4j adaptor for 3rd party at the same time. Then he just picks some SLF4J backend like logback. In fact this is a reason for SLF4J, it is so simple. No log4j config is necessary. – Rostislav Matl Mar 19 '12 at 22:08
-
1@RostislavMatl Are you talking about SLF4J "bridging modules" (http://www.slf4j.org/legacy.html)? These allow you to use a library that uses log4j,... internally and redirect its log messages to SLF4J (which might be backed by logback). This is certainly a great feature if you are the USER of a library. However when you are the DEVELOPER of a library why should you force your users to jump through such hoops? Why not use a facade directly? As the SLF4J page states these solutions are "appropriate for software beyond your control". Please correct me if I have misunderstood you. – Joe23 Mar 20 '12 at 10:12
-
Apparently we talk about different things. You wrote: "if you use log4j but the developer using your library uses logback he will have to include a log4j configuration" - that's not truth. And it's a bad solution at the same time. I did not tell you cannot use SLF4J while developing a new code. I chose the library user point or view because you'll be more often the user then the creator. – Rostislav Matl Mar 21 '12 at 16:24
-
2@RostislavMatl Ah, now I understand. I wrote *"he will have to include"*, and you are saying there are other solutions, i.e. the bridging module. Regarding the point of view, I think the OP wrote from the point of view of the library creator, thus my answer is written in that way as well. – Joe23 Mar 21 '12 at 17:45
-
@RostislavMatl I have updated my answer and added a link to *bridging modules*. However, I don't want to stress the point too much, since the best approach when developing a **new library** is still to use a facade directly I think. Would you agree? – Joe23 Mar 21 '12 at 17:56
-
Yes, I definitely recommend to use SLF4J with logback as backend and unify logging of 3rd party components logging in your environment with the help of the adaptors / bridging modules. – Rostislav Matl Mar 21 '12 at 23:51
The standard solutions for this are:
- Log4J: http://logging.apache.org/log4j/
- SLF4J: http://www.slf4j.org/
- JDK Built-in Logger: https://docs.oracle.com/javase/8/docs/technotes/guides/logging/overview.html
All of them will allow you to configure the log file location through configuration.
The location of your log file is set outside the package, in a logging framework configuration. The config file is usually on classpath. How it looks depends on what logging framework you use - I recommend to go with SLF4J and Logback.

- 5,683
- 3
- 25
- 23

- 4,294
- 4
- 29
- 53
Starting From Java 9 libraries authors should use System#getLogger Facade and let the Developer choose the logging backend framework.
All Java popular logging frameworks implement Service Provider of the new Facade SPI

- 1
- 1