Current thinking on logging?

[Chris]

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?

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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?

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

 

[Jason Cavett]

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?

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.

 

[_weijiang_]

LimpidLog at http://www.acelet.com/limpidlog/
You do not need to hard-code any log statement.
It is an open source program.

 

[Robert Klemme]

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

 

[_weijiang_]

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.

 

[EJP]

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.

 

[_weijiang_]

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.