[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-user
Subject:    Re: Logger serialization
From:       "Trenton D. Adams" <trenta () athabascau ! ca>
Date:       2005-11-29 19:40:21
Message-ID: 438CAEA5.8020109 () athabascau ! ca
[Download RAW message or body]

log4j_rocks@xemaps.com wrote:
> On Nov 28, 2005, at 6:28 PM, Trenton D. Adams wrote:
> 
>> I can't see using anything other than the root logger.  Can you?   Am 
>> I missing something?
> 
> 
> 
> I have 3 reasons for using loggers other than the root logger:
> 
> 1.  Differential logging levels.
> In both development, and in production, it is sometimes useful to  
> increase the logging verbosity for specific classes and packages.  We  
> do this to help identify where problems are originating.  In  Production 
> especially, this is an important tool because we can't put  the 
> production applications into debug to trace through the code and  
> determine where a problem originates.

Can't that be done by simply configuring log4j to increase log level for 
only those classes?  For example by adding 
"log4j.logger.ca.athabascau=DEBUG" to the log4j.properties, where 
"ca.athabascau" is a package name.  Or is the "ca.athabascau" part 
related to the category, and not the class name?  Given that I make 
loggers based on package/class name, I'm not sure.  However, the short 
manual indicates that the "ca.athabascau" part is for filtering based on 
package name, and not category name.

> 
> 
> 2.  Many applications running under a single JVM.
> Our company uses webMethods.  webMethods has a piss-poor logging  
> architecture but fortunately it is a Java-based middle-ware server.
> 
> To get better logging granularity, I created a log4j wrapper service  
> within webMethods.
> 
> Because all our webMethods projects run under a single webMethods  
> server which runs under a single JVM, we create separate appender/ 
> logger pairs for each project.  The appenders identify the separate  log 
> files for each project, and the loggers specify the package  starting 
> point for each project and allow each project to have  separate log 
> levels that are relevant to that project's needs.
> 
> In our webMethods environment, we use the root logger as a default  
> logger for our common services and for those projects that do not  
> properly create their project-specific logger.
> 
> This is a basic paradigm which should work for any environment where  
> many disparate applications must run under a single JVM.
> 
> 
> 3.  Specialized logging.
> The MyJXTA2 project (http://myjxta2.jxta.org/) is an Open Source chat  
> program built on the JXTA networking infrastructure.  In MyJXTA2  there 
> is the general logger defined by the root logger and various  appenders 
> that may be used for File, Console or XML output.  Then,  there is a 
> specialized Chat Log Appender.  This appender has a filter  used to 
> specify only the Chat text (no other trace, debug, info,  warning or 
> error info is captured by this appender).  This appender  creates a 
> stripped-down log message which does not contain most of  the "normal" 
> logging information (e.g., class name, logging level,  MDC, NDC, etc.).
> 
> There is a separate MyJXTA2 Chat Logger that specifies the single  Class 
> that processes all the chat text and the info level that is  used by 
> this class when logging chat text.  No matter what kind of  level is 
> being spcified for the root logger, this separate logger  ensures that 
> we can always have a chat log.
> 
> 
> So, yes.  There are reasons for using loggers other than the root  logger.
> 
> 
> Mike McAngus
> 


-- 
Trenton D. Adams
Systems Analyst/Web Software Engineer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!

__ 
    This communication is intended for the use of the recipient to whom it
    is addressed, and may contain confidential, personal, and or privileged
    information. Please contact us immediately if you are not the intended
    recipient of this communication, and do not copy, distribute, or take
    action relying on it. Any communications received in error, or
    subsequent reply, should be deleted or destroyed.
---

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

[prev in list] [next in list] [prev in thread] [next in thread]