How to determine, what logging system given project uses?
It has signs of log4j, slf4jand logback. Looks like active config file is log4j.properties. The loggers are created in classes by
private static Logger log = LoggerFactory.getLogger(MyClass.class);
the full type of logger is org.slf4j.Logger and the type of factory is org.slf4j.LoggerFactory.
But there are also jars logback-core-0.9.26.jar and logback-classic-0.9.26.jar.
Other jars are slf4j-log4j12-1.6.1.jar, slf4j-api-1.6.1.jar, log4j-1.2.16.jar and commons-logging-1.1.1.jar.
What defines that logback is apparently inactive? How to activate it?
sl4j is a facade, there is no actual implementation. In other words sl4j cannot work alone, underlying logging framework can be log4j, logback, java util logging and so on.
slf4j-log4j12-1.6.1.jar dependency implies that the underlying logging implementation is log4j.
Advantage of this approach is that later on you can switch your logging implementation from Log4j to logback(which is claimed to be better by many) or any other logging framework. Your classes are not tightly coupled to logging framework.
Given the jars you mentioned, I assume the logging system is log4j, accessed through either slf4j or commons logging (maybe provided to satisfy other frameworks' dependencies).
The key here is slf4j-log4j12-1.6.1.jar which instradates slf4j through log4j.
If project code uses slf4j, then asking what logging system it uses is asking a wrong question, in a way. It will use whatever logging framework slf4j finds at runtime. If you are unsure, turn on debugging information on all the relevant libraries:
For log4j, add -Dlog4j.debug to java command line.
For slf4j I remember adding debug code and there printing the class name of ILoggerFactory instance (returned by LoggerFactory.getILoggerFactory()), which reveals what actual logger it will use.
Not sure how to debug logback or commons logging, but I'm sure their docs tell that.
The situation you describe where both logback-classic.jar and slf4j-log4j12.jar are present on the class path is an instance of the "multiple-bindings problem" mentioned in the SLF4J error code documentation. The explication for the relevant error code states:
The warning emitted by SLF4J is just that, a warning. Even when
multiple bindings are present, SLF4J will pick one logging
framework/implementation and bind with it. The way SLF4J picks a
binding is determined by the JVM and for all practical purposes should
be considered random. As of version 1.6.6, SLF4J will name the
framework/implementation class it is actually bound to.
Strangely enough you did not mention this error message in your question. If as you say both logback-classic.jar and slf4j-log4j12.jar are really present on the class path, then SLF4J will definitely print "Multiple bindings were found on the class path" as a warning. If it does not, then only one binding is actually present on the class path.
Related
I'm new to logging and wanted to use slf4j with log4j2 in a project of mine.
The configuration is using a json file.
I know that you can create a configuration during runtime with a ConfigurationFactory or use a file that will be checked if it has changed every time a log statement is made and a given time (or none) has passed.
My question is regarding the json file. Will i have to write my own class to change that file using a json parser or will slf4j/log4j2 change the file for me somehow? If so how?
I was reading through the documentation and googled, but didn't find the answer.
I hope you can help me out. :)
First write you code against the slf4j API. It's mostly a bunch of interfaces, and you don't want to "pollute" your code with non-slf4j API if you're using the slf4j logging interface.
Then you want to package / run with log4j-slf4j-impl-2.0.jar which adapts the slf4j API to the log4j2 API. Then you can configure your log4j2 system like you would if you never used slf4j.
Do not use the log4j-to-slf4j-2.0.jar, as that is intended to make code written to log to log4j loggers put their logging on the slf4j API, and if slf4j then implements that with a slf4j logger, your logging events will be passed between slf4j and log4j in an endless loop.
---- Editing post to address question, as it would be too much to put in a comment ----
slf4j is a logging suite with three main kinds of components.
A set of "input adapters" that take one logging system and pipe it into the slf4j API.
An slf4j API that doesn't make any assumptions about how logging is implemented.
A set of "output adapters" that take the slf4j API calls and cram them into some "other" logging system.
The input adapters typically have names like "logsystem-to-slf4j-version.jar", and should be used when you want to migrate to slf4j but haven't rewritten your code to stop using the "old" logging interface.
The output adapters typically have names like "logsystem-slf4j-impl-version.jar" and only one should be provided to slf4j at runtime.
Because slf4j is unaware of which logging adapter it might use to actually process the log messages, it is unaware of the configuration capabilities of that logging system.
Even worse, while logging typically has a semi-similar interface for the submission of log messages, they have vastly different interfaces for configuring the handling of such messages.
In short, if slf4j only adapts the handling of log messages, not the handling of configuration (which is vastly different between say System.out.println(...) and log4j)
This means that at best, you can filter your log messages at the slf4j API layer; but, there is no guarantee that they will be presented; because the underlying logging implementation may be configured to filter even more messages, or may be replaced with a "no logging at all" implementation.
Within some bounds it is possible to have log4j2 react on runtime values: With properties (which can grab entries from System config or ThreadContext), it's simple enough to inject some dynamism.
I received a project done by another developer (whom I cannot get in touch with right now). In that project, slf4j is used for logging. But I see log4j-1.2.17.jar along with logback-access-1.0.9.jar,logback-classic-1.0.9.jar,logback-core-1.0.9.jar in the classpath. Also both log4j.properties and logback.xml files are in the resources. Now I am confused which implementation is actually used. Can anyone suggest anything?
Update
There is also slf4j-api-1.7.2.jar and slf4j-log4j12-1.7.2.jar in classpath
If you don't see slf4j-api.jar in the class path then, as mentioned below, SLF4J will default to a no-operation implementation. It seems like the other developer was using SLF4J to plug in log4j-1.2.17.jar(log4j) along with logback-access-1.0.9.jar , logback-classic-1.0.9.jar and logback-core-1.0.9.jar(logback) at deployment time.
The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at deployment time.
Before you start using SLF4J, we highly recommend that you read the two-page SLF4J user manual.
Note that SLF4J-enabling your library implies the addition of only a single mandatory dependency, namely slf4j-api.jar. If no binding is found on the class path, then SLF4J will default to a no-operation implementation.
- From SLF4J - Simple Logging Facade for Java
I am using SLF4j and Logback in my application. Now I have the requirement that my application should be embedabble in other applications. This means, that the application can be used as a library in other applications. Everything works as expected except the Logger part. I just can't figure out how to completely disable Logback (this is because the user should bring its own logger implementation). I tried also to find information if it is possible to run Logback in something like a "delegation mode" to allow other SLF4j implementations to hook in, but I did not find anything.
Another approach would be to write a custom Classloader which gets rid of logback when the application starts, but this is very complicated (afaik it is not possible without hacks to remove loaded classes from classloader while the application is running).
Does anyone see a possibility to do this without splitting my application in different modules?
At compile time, you should only have slf4j-api in your classpath.
At runtime, you can choose to add logback in your runtime classpath, and slf4j will use it.
If the other application uses e.g. log4j, they need to add slf4j-log4j instead of logback, as well as slf4j-api and your module.
If they use java.util.logging, they need to add slf4j-jdk14 instead of logback.
In both cases, you might want to tell them which logging categories you use, so they can add it in their log4j or java.util.logging configuration.
I know its a package difference
1) org.apache.log4j.Logger logger = Logger.getLogger(clazz);
2) org.apache.commons.logging.Log log = LogFactory.getLog(clazz);
The first one uses loggers via log4j and the second one uses commons.logging. We have a huge project where in some classes loggers are configured using log4j and in some cases its commons.logging.
I did find a log4j property file though.Is there a similar property file for commons.logging ? Where do I configure for commons-logging ?. I am unable to see the logs generated by commons-logging.
Any help is appreciated.
Yes, commons-logging is a facade API that was suppose to abstract you from underlying logging framework (in practice there was a choice between log4j and java.util.logging) so that you could switch from one to another without touching the code - just by switching libraries available on the CLASSPATH.
Unfortunately due to some design mistakes it had issues with complex class-loading environments, like application servers. Currently it is effectively superseded by slf4j.
In your case I would recommend sticking with one API - either Log4J or commons-logging, even though commons-logging will (most likely) delegate to log4J. You can also migrate to using SLF4J and install bridging APIs, but this is slightly more advanced.
WHen deploying my Spring / Hibernate application, I get the following warning related to logging:
log4j:WARN No appenders could be found for logger (org.springframework.web.context.ContextLoader).
log4j:WARN Please initialize the log4j system properly.
Surprising to me was the lack of information from a Google / SO search. The only thing relevant was this SO post Problem with Commons Logging / Log4j setup in spring webapp with tomcat 6
However, this is even beyond me. Can somebody clarify the logging systems in play here, or point me to a RECENT resource on the matter (there are some ancient google search results that don't really apply). Specifically, the issues I'm wrestling with are:
The distinction among commons-logging, log4j, slf4j and JCL. My understanding is that slf4j is a wrapper, while commons-logging and log4j are actual implementations. I don't know where JCL fits in.
How to configure logging for Spring. What does in the web.xml file, do i need a log4j.properties file or a log4j.xml file? Where does it go, in WEB-INF? Does anything go in my applicationContext.xml file? (sorry but I need to start from zero here).
I am using Hibernate in my project and including via Maven. It seems that Hibernate uses slf4j-simple. I have seen warnings saying that I can't have slf4j-simple and slf4j-log4j both on the classpath. I have not included slf4j-log4j as a dependency, but Hibernate must be including it. How do i solve this problem? Can I force Hibernate to use log4j instead?
Any help would be greatly appreciated. Thanks.
edit:
Thanks for all the answers so far. I am giving these suggestions a try. What about spring web-app specifically? I've seen examples of listeners and parameters and whatnot put into the web.xml file. Is this also required?
commons-logging and SLF4J are both API wrappers around other logging implementations. SLF4J is the more modern of the two, and rather more capable. Log4j is a logging implementation, and pretty much the defacto standard. JUL (short for java.util.logging) is the (generally awful) logging implementation that comes with the JRE. Another log implementation is logback, which is slowly gaining traction, but not at all widespread yet.
log4j.properties and log4j.xml are different ways of configuring log4j, both are equally valid. Which one you use is up to you, although some application servers dictate one or the other. Read the log4j manual to find out how to configure this.
If Hibernate uses SLF4J as its API, that's the choice of the Hibernate developers. However, you can choose which logging implementation SLF4J will delegate to. Again, read the slf4j manual to find out how to select your chosen implementation.
Yes, it's all rather confusing. Given an open choice, SLF4J and Logback is the most capable combination, but you usually don't get an open choice. Different frameworks (like Hibernate and Spring) will potentially use different logging APIs, usually commons-logging or SLF4J, but you can get all those APIs to eventually log to the same underlying implementation (usually log4j).
The distinction among commons-logging, log4j, slf4j and JCL. My understanding is that slf4j is a wrapper, while commons-logging and log4j are actual implementations. I don't know where JCL fits in.
Jakarta Commons Logging (JCL) and Simple Logging Facade for Java SLF4J are both abstractions 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. Commons Logging is known to suffers from class loader problems which is what SLF4J tries to solve (SLF4J is known to be a cleaner library).
Having that said, the fact is that Spring uses Jakarta Commons Logging API (see Logging Dependencies in Spring): Spring is compiled against JCL and Spring makes JCL Log objects available for classes that extend Spring. The is actually the only mandatory external dependency in Spring. This choice has been made because many other frameworks where also using it (e.g. Struts). The idea was to avoid having to have multiple facade libraries on the class path when building applications ("A" for Spring, "B" for Struts, etc). It is however possible to replace JCL by SLF4J if you want to (SFL4J provides bindings to logging frameworks but also a "JCL to SLF4J" bridge). See the mentioned post Logging Dependencies in Spring for all the details.
How to configure logging for Spring. What does in the web.xml file, do i need a log4j.properties file or a log4j.xml file? Where does it go, in WEB-INF? Does anything go in my applicationContext.xml file? (sorry but I need to start from zero here).
To log, you have 1. to decide which implementation you want to use (java.util.logging, log4j or logback), 2. to put the chosen one on the classpath if required (java.util.logging is in Java SE so it doesn't require extra libraries) and 3. to configure it (by putting a config file on the classpath). If you choose to use log4j, just add its jar and a log4j.properties or a more fancy (but more verbose) log4j.xml (this is just another format for the configuration) to the classpath.
I am using Hibernate in my project and including via Maven. It seems that Hibernate uses slf4j-simple. I have seen warnings saying that I can't have slf4j-simple and slf4j-log4j both on the classpath. I have not included slf4j-log4j as a dependency, but Hibernate must be including it. How do i solve this problem? Can I force Hibernate to use log4j instead?
Hibernate utilizes Simple Logging Facade for Java (SLF4J) and, indeed, you can't have several bindings (e.g. slf4j-simple.jar and slf4j-logj12.jar) on the classpath at the same time. Here, you are very likely getting slf4j-simple.jar transitively from another dependency. To solve this problem, run mvn dependency:tree to figure out from where it's coming from and exclude it if required.
And by the way, in your case, I would configure Spring to use SLF4J as Hibernate is using it. Follow the steps in the link mentioned in the first paragraph for that. And I would use logback as logging framework (which the successor of log4j), this is where things happen now.
You need a log4j.properties file in your classpath. Here is a minimal properties file I happened to have created yesterday:
log4j.logger.BillReview=INFO,BillReviewLog
log4j.appender.BillReviewLog=org.apache.log4j.RollingFileAppender
log4j.appender.BillReviewLog.File=BillReview.log
log4j.appender.BillReviewLog.Append=true
log4j.appender.BillReviewLog.MaxFileSize=5000KB
log4j.appender.BillReviewLog.MaxBackupIndex=5
log4j.appender.BillReviewLog.layout=org.apache.log4j.PatternLayout
log4j.appender.BillReviewLog.layout.ConversionPattern=%c %p %-10.10X{server} %-4.4X{user} %d{ISO8601} %m%n
Put that into a log4j.properties file, change all the references to 'BillReview' to something more like your project and that'll log to a file and stop those messages.
Your questions about which logging framework are largely personal choice. Log4j is the old standard and it works fine, Commons logging and slf4j are newer APIs and allow some more complicated use cases.
I'll let some more experienced Gurus than I answer the first bullet.
Answering your second bullet...
You can use either a log4j.properties or log4j.xml file (it doesn't matter which). Whatever you choose you should add it to your classpath (typically it should go in the same directory as your source code). If you are using Spring, a nice way to break your src directory up into logical portions is by using the following directory structure...
src/main/java -- put main source here
src/main/resources -- put resources used by you main source here
src/test/java -- put test source here (for tests)
src/test/resources -- put resources for tests here
You would therefore put your log4j.properties in the src/test/resources directory.
Answering your third bullet...
You can exclude a dependency within a dependency in you pom.xml file by doing the following...
<dependency>
<groupId>org.apache.xbean</groupId>
<artifactId>xbean-spring</artifactId>
<version>${xbean.version}</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
I had problems in the same area while running my tests. I eventually noticed that junit was bringing in slf4j-nop as a dependency, in addition to the slf4j-log4j12 that I wanted. Once I excluded slf4j-nop, it started working.