Advice Required on log4j

Can anyone give advice concerning a sensible strategy for using log4j in a servlet environment? I'm just starting to look at it and its becoming obvious that if I'm going to use it successfully then I need to plan its use carefully.

My application consists of one servlet which acts as a message router, with a number of classes which are called from it. I currently declare one public static logger in the top level servlet and then refer to it through out the application. Is this a sensible thing to do?

I've got two appenders at the moment - one to System.out and one to a file. They have different treshholds and I'm using the configureAndWait method to allow me to switch at runtime.

I'm also hoping to use it as a way of spotting performance problems in the application by logging entry and exit points from methods which I think may be causing me problems. Is there a better way of getting this sort of profiling information - I'm running on HP_UX and have no money to spend it that has any baring on the answer! If there are no profiling tools, am I better to create a new Level ( called Performance or something ) and set it at a level below DEBUG?

Any advice will be gratefully received.


Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jim CakalicSenior Developer/ArchitectCommented:
The recommended usage pattern is typically one static Logger per class -- not for the entire application. This allows finer run-time tuning of logging and permits the Logger (aka Category) to be inserted in the log output to provide some locality of reference w/o resorting to use of the poorly performing introspection mechanism to find class/method name.

Logging on entry/exit of a method is not likely to provide you, I think, with the kind of information that you need. First of all, unless your methods are very poor performers, they are likely not likely to run long enough for you to see a measurable number of milliseconds on each execution. Second, it would be difficult (impossible?) to determine whether it is the logging or your method that is responsible for the measurement. Finally, it would be quite onerous to look at any reasonable measurement log and attempt to gather from it a profile by hand. You'd have to write some log processing tools to aggregate and summarize the results. Even then, you couldn't really be sure of the results, IMHO.

I haven't personally used it, but there is a free load/performance testing tool from Jakarta call JMeter.

You might also look at IBM's Jinsight alphaWorks technology. It is available for free download with a 90-day trial license.

Finally, here's a link to an article at JavaWorld which describes the issues/problems with performance analysis -- I forgot to mention how the garbage collector skews "real-time" measurements -- and discusses the JVMPI (JVM Profiler Interface) with code showing how it can be used to take accurate code timings. Probably worth a look if you are going to need to "grow your own" profiler.

Best regards,
Jim Cakalic
howesdAuthor Commented:
Thanks for that Jim.

My app currently has about 70 classes in it, and it seems like that would become quite awkward to manage if I had a logger for each class. Wouldn't I need a configuration (or properties) file for each class/logger to provide the level of fine run-time control that you speak of?

The app ( which should really have been a soap app but I couldn't figure out how to do it quickly enough ) handles about 12 types of input messages. I'm thinking that may be one logger for each of these messages might be a suitable compromise.

I'm having a little difficulty in working out how the different loggers relate to each other, but I must confess that I haven't spend a lot of time reading the manual or experimenting yet.

As far as your point about entry and exit logging is concerned, I agree with what you say and will look in to the tools you mentioned. My app is not scaling terribly well and just using entry and exit logging did help me to identfy one area of weakness - JDOM schema validation appears to take approx 200 milliseconds when one user is accessing the app, but this degrades to over two seconds once I get 20 simultaneous connections. Also, I've fairly new to Java and I'm fairly confident that I'll be able to write some poorly performing methods of my own :)

Jim CakalicSenior Developer/ArchitectCommented:
If you _need_ to have the fine-grained run time control over logging output, then you could configure it if you had already categorized output using the full package names of classes in your application. If you don't categorize the namespace somehow, then you can't configure. However, it isn't necessary to use the full category (now called logger) hierarchy in your configuration. You can simply use the root category/logger with a single appender and everything will go to one place. So you build in the ability to greater configuration but you don't have to use it until you really need it.

Some of your confusion about loggers may be because of the unfortunate (IMHO) choice of names. In previous versions of log4j this concept was called a category. Alignment of names with the infamous java.logging API of JDK 1.4 caused the name shift. This class really doesn't represent an output stream to some data sink. That is an appender, which is what actually writes your formatted log entry to some place like a file, a socket, a JMS queue, an SMTP server for email, a database, etc. The logger class primarily provides a named handle for configuring the level of logging in a particular part of the application.

Heres some more log4j info that might prove useful:


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
howesdAuthor Commented:
Thanks Jim - I spent the time to read the manual and I've got what I think to be a workable way of managing it.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.