logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Custom level question
Date Wed, 03 Aug 2005 15:14:46 GMT

On Aug 3, 2005, at 9:35 AM, Steve Pruitt wrote:

> Logger / level design is my million dollar question.  My application
> will have an adminstration console where logging levels, appenders,  
> and
> layout can be specified.  I'm hiding the details of log4j and  
> presenting
> them some simple choices.  Log to a console or file.  Select browser
> format (i.e. html) or xml format.  Email notification, etc.  They can
> also turn logging on or off, or specify INFO or ERROR.
>
> Some sites may only want to track user login and logout sessions.   
> So, I
> thought of adding a level named SESSION to facilitate this choice.  I
> also need to persist the choices made so when the application is
> restarted the logging choices are re-established.  I am trying to do
> this without an additional config file - this may be a problem.  I  
> plan
> to modify and write out the log4j config file whenever a change  
> occurs -
> hoping I can codify the changes strictly within the confines of the
> log4j config file syntax.  My thinking is the SESSION level helps  
> me do
> this as this specific level doesn't exist.

Using a specific branch in the logger hierarchy for session related  
logging requests is the right way to do that.  The art is to match  
the logger hierarchy to the potential audiences and their areas of  
concerns.  Most people are introduced to log4j with examples that use  
the class name as logger name for one and only logger in each class.   
That is a good pattern for messages for diagnosticians and developers  
who are familiar with the code base, since they can map the behavior  
they are investigating to a particular set of classes and turn off  
everything else.

However, that pattern is not effective when the intended audience is  
not familiar with the code base or their concerns don't align  
themselves with the code structure.  In this case, it sounds like you  
have an audience that is interested in either auditing use of the  
system or looking for potential security concerns and their interests  
are not organized along class boundaries.  If you have an imagined  
audience that would be interested log in and log out messages,  but  
not diagnostic messages, can you imagine other things that they could  
also be interested in?

For example, if you have some auditing the use of a system, a  
successful log in might be of interest and assigned an INFO level.   
However, repeated unsuccessful logins might warrant a WARN.  If there  
are revalidations of the connection, those might be assigned a DEBUG  
level.  They aren't things that the audience would typically want to  
know unless they are investigating a problem.

I'd start by using a logger named "session", "security.session",  
"audit.session" or similar and then branch out into the other areas  
of concern for this imagined audience.


>
> As all good frameworks, log4j gives lots of options and flexibility.
> I'm thinking of a logger hierarchy where the appender is the -
> potentially - least used as you go up the hierarchy.  Something like
> File -> Console - > Email.  I hope this makes sense.


Sorry, didn't follow that paragraph.

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


Mime
View raw message