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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
