logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: Logging Strategy
Date Wed, 04 Aug 2004 17:44:56 GMT

Be careful deciding on strategy based on fears alone, rather than actual
experimentation or benchmarking, especially with a tool that's new to
you such as log4j.  We use Loggers that are named the same as their
class, so we have one Logger per class.  We have thousands of classes at
runtime in the JVM and it works fine, but then again our apps are
memory-hungry to the point where log4j is not a significant memory usage
factor.  We've found this configuration to be priceless, because
although you can make the case that a package is a functional unit and
not a class, logging from an entire package can become very verbose very

Yoav Shapira
Millennium Research Informatics

>-----Original Message-----
>From: Edward Howe [mailto:ehowe@employease.com]
>Sent: Wednesday, August 04, 2004 10:33 AM
>To: 'Log4J Users List'
>Subject: RE: Logging Strategy
>I am currently developing such a strategy while introducing log4j to an
>existing web-based application.  Not having experience with log4j, this
>thread is timely.
>My tenative plan is to use package-level loggers.  So for each class in
>package com.foo.bar, I would have:
>  private static final Logger LOG = Logger.getLogger("com.foo.bar");
>My reasoning is that packages generally correspond to functional areas
>our app, and would provide finer granularity than naming loggers by
>functional areas
>(http://logging.apache.org/log4j/docs/FAQ.html#namingLoggers).  I fear
>using class names would result in a huge number of loggers (and memory
>overhead), so package names seemed a reasonable compromise.  (We have
>classes vs. >350 packages.)
>Ed Howe
>-----Original Message-----
>From: Paul Smith [mailto:psmith@aconex.com]
>Sent: Tuesday, August 03, 2004 6:32 PM
>To: 'Log4J Users List'
>Subject: RE: Logging Strategy
>A Good Strategy is one that works for you, and a bad is one that
>But since people are different, a strategy may be good or bad depending
>who uses it.
>So I can only outline what strategy I usually follow, and maybe
>others to outline their own.  Maybe then we could take the results and
>them all in a Wiki page, with a discussion of advantages/disadvantages
>each.  Might be a useful resource.
>Anyway, here's what I do, for what it's worth.
>* For each class, declare a class level logger in the usual form:
>  private static final Logger LOG = Logger.getLogger(MyClass.class);
>  This logger is used mostly for DEBUG logging, logging method params,
>level information, maybe timing information etc.
>* If the Class in question forms part of logical sub-system of the
>application, I create an Subsystem logger as well, in the same class:
>  private static final Logger MYSUBSYSTEM_LOG =
>I use this logger mostly for INFO/WARN/ERROR, because generally those
>of logs are Application related, rather than class specific, and it's
>generally more useful to aggregate those types of logs into the same
>Occasionally, a specific log statement might be kind of both class and
>application related, and so in this case, I would log the message to
>Loggers.  Somewhat duplicated, but sometimes when you are trying to
>what is happening you might want to focus from an Application
>(so, a lot of classes spread by the way a thread would use it), or from
>package, or class perspective.  When you might need to do either at any
>point, it's useful to have that up your sleeve.
>This gives me the ability to have all application logs going where I
>because I could just attach the appender to the 'myapplication' logger,
>could route sub-system logs somewhere else, or both.
>When I need to focus on specific class activity, I can dynamically
>appender to a package logger, or to the class-specific logger, and
>what is happening.
>The above approach, I think, is what will benefit from the new Domain
>concept Ceki is developing, but I'm not really that sure, I'll leave
>comment on that.
>What do other people do?
>Paul Smith
>> -----Original Message-----
>> From: Allistair Crossley [mailto:Allistair.Crossley@QAS.com]
>> Sent: Wednesday, August 04, 2004 1:04 AM
>> To: log4j-user@logging.apache.org
>> Subject: Logging Strategy
>> Hi All,
>> This question is more of a logging strategy question.
>> I have architected our intranet using a Struts architecture which
>> backend subsystems like SQL Server, Hibernate, Content Management
>> etc.. via J2EE BluePrint design patterns and so on.
>> Because of the number of subsystems and applications within the
>> architecture, it is helpful to partition up these as different logs.
>> At the moment I have such a mess of a log4j strategy and I would like
>> clean it up. Currently I have 2 strategies in place:
>> 1) Some classes acquire a named logger, e.g
>> getLogger("TheNameOfAnAppender"). So an application called
>> might only ever use the HolidayFormsLogger and all debug, info, error
>> so on goes in there.
>> 2) I also assign appenders to packages based on type of class. So in
>> Struts app we have Actions, Data Transfer Objects and Data Access
>> In each of these classes I get a logger with
>> and in log4j properties use
>> com.comp.blah.actions=debug, AppenderName1
>> com.comp.blah.dto=debug, AppenderName2
>> com.comp.blah.dao=debug, AppenderName3
>> 3) I found that examining each log for errors was time consuming.
>> Therefore I created a named logger called ErrorAppender and every
>> has a loggerErr = Logger.getLogger("ErrorAppender") and write to it
so I
>> can see error level logging in one place.
>> I don't imagine I have got this very right at all and I would so much
>> appreciate some guidance. I have ordered the O'Reilly Log4J book but
>> been waiting for 3 weeks for it to arrive, so I am having to ask the
>> :)
>> Your advice appreciated as ever, Allistair.
>> -------------------------------------------------------
>> QAS Ltd.
>> Developers of QuickAddress Software
>> <a href="http://www.qas.com">www.qas.com</a>
>> Registered in England: No 2582055
>> Registered in Australia: No 082 851 474
>> -------------------------------------------------------
>> </FONT>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org

This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message