I'm curious if there is a prescribed approach to defining loggers. Let me
state what my assumption is. I assume that normally if some piece of code
wants to log events/messages that it should create a logger for itself. I
guess a reasonable name to use is the class name itself. In terms of logger
configuration I would expect that no loggers are specified in the log4j
configuration UNLESS is needs settings other than the default. The root logger
would specify the default settings, eg. level and appenders. If some piece of
code tied to a logger needs to enable tracing in order to debug an issue then
you would add that logger to the configuration and set the level less specific
for that logger. Is this a typical and reasonable approach?
I asked because we have the need for a new type of event. To have this event
flow to where we want it to flow the plan is to have a custom level and have
all events at that level captured by a specific appender. My assumption was
that for existing applications we'd just need to add our appender to the root
and add our custom level. The app would need to be modified to log our new
event at the custom level. However, someone suggested that we could also
create a separate logger for this event. My thinking is that while we don't
ever want to turn off logging of this event, loggers represent "event sources",
e.g the code raising the events and thus having multiple different pieces of
code use the same logger wouldn't allow you to turn on/off logging from those
different sections of code independently. I think the current configuration
includes all the loggers. Normally I would expect there to be many, on the
order of 10's or 100's, loggers within an application. However, in the case I
was given there were only a handful because I think this handful is shared. So
as I mentioned, this doesn't sound like an ideal design as you have less
granularity on what you can turn on/off.
Thanks,
Nick
