I’ve written a simple console app which uses JPA to connect to a MySQL database. The actual reading/writing of data is working, but logging seems to be screwed up. Each EntityManager instance that I create seems to add its own log4j appender to the console. So, since I have three EntityManager instances in my app, I get three extra lines in my console output in addition to the “real” console output line I want. Here’s an example. The first line is from my “real” appender, the other three seem to be coming from the EntityManager’s appender:
08:31:58,970 com.electricgearbox.app.ProcessDataItemApp DEBUG main foobar:169 - geoEntityDao.getByCompositeKey took 81 milliseconds
0 [main] DEBUG foobar - geoEntityDao.getByCompositeKey took 81 milliseconds
0 [main] DEBUG foobar - geoEntityDao.getByCompositeKey took 81 milliseconds
0 [main] DEBUG foobar - geoEntityDao.getByCompositeKey took 81 milliseconds
Here is my log4j configuration:
log4j.rootCategory=WARN, mylog
log4j.appender.mylog=org.apache.log4j.ConsoleAppender
log4j.appender.mylog.layout=org.apache.log4j.PatternLayout
log4j.appender.mylog.layout.ConversionPattern=%d{ABSOLUTE} %C %5p %t %c{2}:%L - %m%n
log4j.category.foobar=DEBUG
I would like to be able to turn off this behavior and just get the console lines I want. I don’t seem to be able to “crack the code” on how to do that – any help would be appreciated…
Additional information: It appears that there are two things going on here. The first is the log4j appender additivity setting, which is true by default. Re-reading the sparse log4j documentation (http://logging.apache.org/log4j/1.2/manual.html) I came across this:
Each enabled logging request for a given logger will be forwarded to all the appenders in that logger as well as the appenders higher in the hierarchy.
What that does NOT mention is that it apparently will do this regardless of the setting of the loggers higher in the hierarchy.
What this means, or seems to mean in my case, was that although my root logger was set to WARN, the appenders attached to it by the Hibernate classes were still being used by DEBUG-level messages. This is the opposite of what I would expect to happen. I’m not sure if this represents a bug in the Hibernate 4.0.1 JPA implementation or just a lack of documentation on the part of log4j, or a glitch between log4j and slf4j (used by Hibernate).
The second thing that’s going on is that every time you create an EntityManager object, it seems to add an appender to your log4j logging tree, so if you have multiple EntityManagers, you get multiple logging messages. This I’m pretty sure is a bug in the Hibernate logging.
Still looking for an explanation or an example of how this “additivity” works in practice with log4j – it seems to be working in the reverse of what I would expect from the limited documentation. That is, appenders seem to be passed DOWN the logging tree instead of logging events being passed UP.
Here is what I have so far for my (revised) log4j properties file, and it appears to be working:
log4j.rootCategory=WARN, mylog
# logger "root" logs at WARN level to appender "mylog"
log4j.appender.mylog=org.apache.log4j.ConsoleAppender
log4j.appender.mylog.layout=org.apache.log4j.PatternLayout
# Logger "foobar" logs at DEBUG level to appender "bootylog"
log4j.category.foobar=DEBUG, bootylog
log4j.appender.bootylog=org.apache.log4j.ConsoleAppender
log4j.appender.bootylog.layout=org.apache.log4j.PatternLayout
log4j.appender.bootylog.layout.ConversionPattern=%d{ABSOLUTE} %C %5p %t %c{2}:%L - %m%n
# additivity is off
log4j.additivity.foobar=false
log4j.additivity.org.hibernate=false
This gives me the following output, which is exactly what I want:
11:15:43,622 com.electricgearbox.app.ProcessDataItemApp DEBUG main foobar:152 - geoDataItemDao.create took 5 milliseconds
11:15:43,624 com.electricgearbox.app.ProcessDataItemApp DEBUG main foobar:166 - geoEntityDao.getByCompositeKey took 2 milliseconds
11:15:43,626 com.electricgearbox.app.ProcessDataItemApp DEBUG main foobar:159 - dataEntityDao.getDataEntityByFieldCode took 1 milliseconds
Finally, I highly recommend to anyone who is having problems with log4j that they turn on this command line option when they run their app:
-Dlog4j.debug
It appears that there are two things going on here. The first is the log4j appender additivity setting, which is true by default. Re-reading the sparse log4j documentation (http://logging.apache.org/log4j/1.2/manual.html) I came across this:
What that does NOT mention is that it apparently will do this regardless of the setting of the loggers higher in the hierarchy.
What this means, or seems to mean in my case, was that although my root logger was set to WARN, the appenders attached to it by the Hibernate classes were still being used by DEBUG-level messages. This is the opposite of what I would expect to happen. I’m not sure if this represents a bug in the Hibernate 4.0.1 JPA implementation or just a lack of documentation on the part of log4j, or a glitch between log4j and slf4j (used by Hibernate).
The second thing that’s going on is that every time you create an EntityManager object, it seems to add an appender to your log4j logging tree, so if you have multiple EntityManagers, you get multiple logging messages. This I’m pretty sure is a bug in the Hibernate logging.
Still looking for an explanation or an example of how this “additivity” works in practice with log4j – it seems to be working in the reverse of what I would expect from the limited documentation. That is, appenders seem to be passed DOWN the logging tree instead of logging events being passed UP.
Here is what I have so far for my (revised) log4j properties file, and it appears to be working:
This gives me the following output, which is exactly what I want:
Finally, I highly recommend to anyone who is having problems with log4j that they turn on this command line option when they run their app: