logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pat Felsted" <pfels...@novell.com>
Subject Re: auditing and log4j
Date Wed, 14 Jun 2006 23:54:46 GMT
Thanks for the response.  So are you suggesting there is a better way to
audit, since you say the purpose of log4j is diagnostics?  If so do you
have suggestions?
Thanks again.

>>> Curt Arnold <carnold@apache.org> 6/14/2006 5:36 PM >>>

On Jun 14, 2006, at 5:47 PM, Pat Felsted wrote:

> I am trying to get a feel of some usage of log4j pertaining to  
> application auditing.  Do you all feel that many use it more for  
> debugging or is auditing also a common use of it?  If it is used  
> for auditing would it make sense to have a audit method?  I have  
> searched the archives and not seen any talk of audit.  Are there  
> projects or communities that use log4j for auditing that you can  
> refer me to?
> Thanks.
> Pat

Additional discussion would be best handled on log4j-user.  This list 

is reserved for discussions that affect the Logging Services Project  
as a whole or don't fit into any of the existing logging frameworks.

The most common use of log4j is to process what I would call  
"diagnostic" messages.  Messages that are intended to help a  
diagnostician (developer or administrator) resolve some observed  
problem.  Since in many cases interpreting these messages require  
some understanding of the code and program flow, it is natural that  
class names are used as logger names.

Since that pattern is so prevalent, many people that loggers have to  
be named after classes and log4j is only useful for diagnostic  
logging.  For "business" or "audit" messages, the class name is not  
the most useful organizational pattern since the auditor may not have 

knowledge of the code and program flow.  For this type of use, you  
might want to name loggers something like "audit.security" or  
"audit.customer.address".  In your configuration, you could set the  
root logger to handle diagnostic messages and then set the "audit"  
logger to go to a different destination (and possibly set additivity  
to false so audit messages don't flow into the diagnostic log).

Your suggestion of an audit method is likely a suggestion that there  
should be an AUDIT level like the existing DEBUG, INFO, WARN, etc.   
However, I believe that "audit" is more an indication of the target  
audience of the message and therefore is appropriately done using the 

logger name which exists to categorize messages by topic or intended  
audience.  If you did treat AUDIT as a level, you would lose the  
distinction between a severe audit message (when an action might  
break a law or cause serious financial harm) and informational audit  
messages (like a particular user logged out) unless you added levels  

View raw message