 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2006Current thinking on logging?
We need to reimplement logging in our app. (It uses an old, home-grown logger). I have found quite a bit on the web discussing Log4j vs JDK logging vs Commons Logging. All of it is old, though, written before JDK 1.5 and 1.6 became available. What is the current thinking on the best way to do logging? My thoughts so far: 1. We have extreme performance requirements. We need to make several log entries for every hit on consumer websites with heavy traffic. 2. Everything I read says log4j is better, but we ship a commercial app, and I really don't want to include yet another .jar file. That means one more external dependency and one more opportunity for conflicting versions, etc. All things being equal, using something built into the JDK would be better. 3. Based on personal experience, I can say that commons logging is a mistake. It causes classloader hell. We can't always control the environments we run in. Have there been significant improvements to JDK logging since version 1.4? Or are we better off going with Log4j? > We need to reimplement logging in our app. (It uses an old, home-grown > logger). I have found quite a bit on the web discussing Log4j vs JDK [quoted text clipped - 20 lines] > Have there been significant improvements to JDK logging since version > 1.4? Or are we better off going with Log4j? I am all for log4j. Better performance. More appenders. And I would be very surprised if JEE app did not need log4j for something meaning that you would need to have it anyway. Arne > We need to reimplement logging in our app. (It uses an old, home-grown > logger). I have found quite a bit on the web discussing Log4j vs JDK [quoted text clipped - 20 lines] > Have there been significant improvements to JDK logging since version > 1.4? Or are we better off going with Log4j? Something else you *may* want to look into is AspectJ. Because AspectJ is designed to improve modularity, you may find this to be a good solution. LimpidLog at http://www.acelet.com/limpidlog/ You do not need to hard-code any log statement. It is an open source program. > We need to reimplement logging in our app. (It uses an old, home-grown > logger). I have found quite a bit on the web discussing Log4j vs JDK [quoted text clipped - 20 lines] > Have there been significant improvements to JDK logging since version > 1.4? Or are we better off going with Log4j? > LimpidLog at http://www.acelet.com/limpidlog/ > You do not need to hard-code any log statement. > It is an open source program. Sounds interesting. Do you have any performance data? Is it as fast as other logging frameworks? The page mentions only the "The performance price to pay for idle LimpidLog" which is not really that interesting. Kind regards robert When everything is okay, you do not need logging. In that case, LimpidLog is idle. The performance price is almost nothing. When some thing is wrong, you need logging. You dynamically re-configure it. Then the performance price is higher than other logging: LimpidLog logs more than other logging. But the performance price is only for the registered classes. You probably know which classes may have problems. The logging for unregistered classes is still idle and no performance price. So the overall price should be lower than other logging. The other thing: how do you read your log records? SuperLogging at http://www.acelet.com/super/SuperDebugger/index.html will read records of LimpidLog. You do source level debugging. It even allows you go to previous step. The performance price occurs only for registered classes, and only when you want log at run time. For Log4J or JDK logging, if you can not dynamically reconfigure them, you pay performace price all the time, even there is no issues. In that case, your log files are liablity, not asset. > > LimpidLog at http://www.acelet.com/limpidlog/ > > You do not need to hard-code any log statement. [quoted text clipped - 7 lines] > > robert > 1. We have extreme performance requirements. We need to make several log > entries for every hit on consumer websites with heavy traffic. If you have extreme performance requirements I would look at the IBM Logging package for Java from alphaworks. It despatches all logging on separate threads so there is minimal impact on the application. Another thread to do the logging will make things worse! Someone has to do the logging. The logging thread will compete resources (memory, cpu, network...) with your application. The grand total work will not be reduced, but overhead added. There are other issues as well. See http://www.acelet.com/whitepaper/loggingInJ2eeWorld.html. > > 1. We have extreme performance requirements. We need to make several log > > entries for every hit on consumer websites with heavy traffic. > > If you have extreme performance requirements I would look at the IBM > Logging package for Java from alphaworks. It despatches all logging on > separate threads so there is minimal impact on the application. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.