Advice Required on log4j

Posted on 2002-05-31
Last Modified: 2008-02-01
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.


Question by:howesd
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
LVL 19

Expert Comment

by:Jim Cakalic
ID: 7047454
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

Author Comment

ID: 7049704
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 :)

LVL 19

Accepted Solution

Jim Cakalic earned 200 total points
ID: 7052135
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:


Author Comment

ID: 7054656
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.


Featured Post

Free Tool: Postgres Monitoring System

A PHP and Perl based system to collect and display usage statistics from PostgreSQL databases.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

INTRODUCTION Working with files is a moderately common task in Java.  For most projects hard coding the file names, using parameters in configuration files, or using command-line arguments is sufficient.   However, when your application has vi…
Java contains several comparison operators (e.g., <, <=, >, >=, ==, !=) that allow you to compare primitive values. However, these operators cannot be used to compare the contents of objects. Interface Comparable is used to allow objects of a cl…
Viewers learn about the scanner class in this video and are introduced to receiving user input for their programs. Additionally, objects, conditional statements, and loops are used to help reinforce the concepts. Introduce Scanner class: Importing…
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question